[Bug c++/60113] Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60113 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.7.3 Resolution|--- |FIXED Known to fail||4.6.4 --- Comment #7 from Marc Glisse glisse at gcc dot gnu.org --- Seems to have been fixed a while ago.
[Bug c/60117] simd reduction clause suppresses simd auto-vectorization when -fopenmp is set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60117 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 --- If the inner loop body is written as x = a[i__] x ? a[i__] : x; then we actually do vectorize with -Ofast -fopenmp-simd, but for some reason the vectorized loop is optimized away as dead later on. For vectorization of the original loop, not sure if we can safely transform omp simd array conditional stores into unconditional read + conditional operation + unconditional store, or if we should (and why don't we) transform those into MASK_STORE.
[Bug fortran/55762] Diagnostic: Passing a procedure to LEN should tell that one has passed a procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55762 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the record the test uses invalid recursive I/O, hence hangs on darwin (see pr30617).
[Bug target/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116
--- Comment #11 from Uroš Bizjak ubizjak at gmail dot com ---
OK, confirmed using -Os -m32 with
gcc version 4.9.0 20140207 (experimental) [trunk revision 207597] (GCC)
on CentOS 5.10.
It looks like a fault in the combine pass.
Before combine, we have:
...
(insn 14 11 15 2 (set (reg:SI 101 [ D.1782 ])
(mem/c:SI (symbol_ref:SI (d) [flags 0x2] var_decl 0x2b47ff9e1ed8d)
[2 d+0 S4 A32])) t.c:18 90 {*movsi_internal}
(nil))
...
(insn 33 32 34 5 (set (reg:SI 113 [ D.1782 ])
(sign_extend:SI (reg:QI 91 [ D.1785 ]))) t.c:17 148 {extendqisi2}
(nil))
(insn 34 33 35 5 (set (reg:SI 114 [ D.1782 ])
(not:SI (reg:SI 113 [ D.1782 ]))) t.c:17 510 {*one_cmplsi2_1}
(expr_list:REG_DEAD (reg:SI 113 [ D.1782 ])
(nil)))
(insn 35 34 37 5 (parallel [
(set (reg:DI 115 [ D.1786 ])
(sign_extend:DI (reg:SI 114 [ D.1782 ])))
(clobber (reg:CC 17 flags))
(clobber (scratch:SI))
]) t.c:17 143 {extendsidi2_1}
(expr_list:REG_DEAD (reg:SI 114 [ D.1782 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 37 35 38 5 (parallel [
(set (reg:SI 117)
(ior:SI (subreg:SI (reg:DI 115 [ D.1786 ]) 0)
(subreg:SI (reg:DI 115 [ D.1786 ]) 4)))
(clobber (reg:CC 17 flags))
]) t.c:17 420 {*iorsi_1}
(expr_list:REG_DEAD (reg:DI 115 [ D.1786 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 38 37 39 5 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 117)
(const_int 0 [0]))) t.c:17 3 {*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg:SI 117)
(nil)))
(insn 39 38 41 5 (set (reg:QI 119)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) t.c:17 624 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
(insn 41 39 83 5 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 101 [ D.1782 ])
(const_int 0 [0]))) t.c:18 3 {*cmpsi_ccno_1}
(nil))
(insn 83 41 42 5 (set (reg:SI 122 [ D.1787 ])
(zero_extend:SI (reg:QI 119))) 138 {*zero_extendqisi2}
(expr_list:REG_DEAD (reg:QI 119)
(nil)))
(jump_insn 42 83 43 5 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 47)
(pc))) t.c:18 628 {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 5000 (nil)))
- 47)
Please note (insn 41) that sets flags for (jump_insn 42), comparing (reg:SI
101) a.k.a d with zero.
Later, combine mass-deletes everything from (insn 33) to (insn 83) to
substitute (insn 83) with constant load:
...
(insn 14 11 15 2 (set (reg:SI 101 [ D.1782 ])
(mem/c:SI (symbol_ref:SI (d) [flags 0x2] var_decl 0x2b47ff9e1ed8d)
[2 d+0 S4 A32])) t.c:18 90 {*movsi_internal}
(nil))
...
(note 33 32 34 5 NOTE_INSN_DELETED)
(note 34 33 35 5 NOTE_INSN_DELETED)
(note 35 34 37 5 NOTE_INSN_DELETED)
(note 37 35 39 5 NOTE_INSN_DELETED)
(note 39 37 41 5 NOTE_INSN_DELETED)
(note 41 39 83 5 NOTE_INSN_DELETED)
(insn 83 41 42 5 (set (reg:SI 122 [ D.1787 ])
(const_int 1 [0x1])) 90 {*movsi_internal}
(nil))
(jump_insn 42 83 43 5 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 47)
(pc))) t.c:18 628 {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 5000 (nil)))
- 47)
Unfortunately unrelated (insn 41) is also killed, so flags are taken from
unrelated operation (that happens to be insn 32, just above insn 33).
Things go downhill from there.
[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Component|target |rtl-optimization --- Comment #12 from Uroš Bizjak ubizjak at gmail dot com --- Re-confirmed as rtl-optimization problem.
[Bug rtl-optimization/49847] [4.7/4.8/4.9 Regression] NULL deref in fold_rtx (prev_insn_cc0 == NULL)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49847
--- Comment #25 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Jeffrey A. Law from comment #24)
This is a mess.
As noted in the other comments, we're considering a cc0-setter as a
potentially trapping insn. As a result the cc0-setter and cc0-consumer end
up in different blocks.
That's bad on so many levels and fixing it by hacking up fold_rtx like
this just papers over the fundamental problem (though I must admit from a
pragmatic standpoint, it's pretty effective).
One could argue that the CFG building code could be tweaked so that a
cc0-setter is never considered the end of a block. The downside of that is
we're lying to the compiler about the true nature of the CFG. But that
little white lie may be acceptable. I haven't looked into how ugly that
would be to implement.
Well, it re-exposes the original problem of not properly handling EH
with -fnon-call-exception and trapping FP comparisons? I don't recall
all the issues with the original case I installed the change (at least
we do consider GIMPLE_CONDs as possibly trapping, just we don't allow
a possibly throwing condition in a GIMPLE_COND).
One fix for backends where cc0 setter and consumer
may not be separated is to duplicate the comparison like
bb
...
g = 0.0; // stmt ending BB with EH edges
bb
if (g = 0.0) // redundant compare, but with NOTHROW set
...
Or to revert the original change and think of a better fix.
But certainly you can't rely on the IL being
if (g = 0.0)
instead of (what gimplification forces now)
bool tem = g = 0.0;
bb
if (tem != 0)
because with -fnon-call-exceptions writing that literally in C++ and
compiling with -O0 will yield exactly the same issue as you hit it
now (separated cc0 setter / consumer).
So reverting wouldn't be a real fix. Testcase:
int foo (double x)
{
try {
bool cond = x = 0.0;
if (cond)
return 1;
return 0;
}
catch (...)
{
return -1;
}
}
Where we shouldn't ICE when reverting the original fix and which at -O0
produces exactly the same issue you face now.
Best it into a runtime testcase that properly catches a trapping compare.
Richard.
[Bug fortran/49636] [F03] ASSOCIATE construct confused with slightly complicated case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-10 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed on 4.7, 4.8, and trunk (4.9 r207643). At r207649, compiling the test gives the following ICE: pr49636.f90:14:0: internal compiler error: in gfc_get_element_type, at fortran/trans-types.c:1183 print '( i_bad=, 3I10)', i(1:3) It is caused by r207646 Author:pault Date:Sun Feb 9 20:50:21 2014 UTC (12 hours, 41 minutes ago) Changed paths:5 Log Message: 2014-02-09 Paul Thomas pa...@gcc.gnu.org PR fortran/57522 * resolve.c (resolve_assoc_var): Set the subref_array_pointer attribute for the 'associate-name' if necessary. * trans-stmt.c (trans_associate_var): If the 'associate-name' is a subref_array_pointer, assign the element size of the associate variable to 'span'. 2014-02-09 Paul Thomas pa...@gcc.gnu.org PR fortran/57522 * gfortran.dg/associated_target_5.f03 : New test
[Bug ipa/60120] wrong code (for code with the optimize attribute) at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60120 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-10 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- This looks like a dup of PR60062 to me - we call fn1 with the argument on the stack but fn1 expects it in %eax. Fixed on trunk and thus doesn't reproduce there.
[Bug ipa/60120] wrong code (for code with the optimize attribute) at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60120 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 60062 ***
[Bug target/60062] [4.7/4.8 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work|4.8.3 |4.9.0 Target Milestone|4.9.0 |4.7.4 Summary|[4.7/4.9 Regression] wrong |[4.7/4.8 Regression] wrong |code (for code with the |code (for code with the |optimize attribute) at -O1 |optimize attribute) at -O1 |and above on|and above on |x86_64-linux-gnu in 32-bit |x86_64-linux-gnu in 32-bit |mode|mode --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk, latent on the branches (see duplicates).
[Bug target/60062] [4.7/4.8 Regression] wrong code (for code with the optimize attribute) at -O1 and above on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60062 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- *** Bug 60120 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P2
[Bug tree-optimization/60115] [4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- Mine then.
[Bug tree-optimization/60115] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Known to work||4.8.2 Target Milestone|4.9.0 |4.8.3 Summary|[4.9 Regression] wrong code |[4.8/4.9 Regression] wrong |at -O3 on x86_64-linux-gnu |code at -O3 on ||x86_64-linux-gnu Known to fail||4.8.3, 4.9.0
[Bug c++/60131] New: RTL check fail in rhs_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60131 Bug ID: 60131 Summary: RTL check fail in rhs_regno Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 32095 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32095action=edit gzipped C++ source code I just compiled the attached code with gcc trunk dated 20140209 on a x86_64 box with flag -O2 and it said /home/dcb/clang/llvm/lib/Target/R600/SIInstrInfo.cpp: In member function ‘const llvm::TargetRegister Class* llvm::SIInstrInfo::getOpRegClass(const llvm::MachineInstr, unsigned int) const’: /home/dcb/clang/llvm/lib/Target/R600/SIInstrInfo.cpp:467:1: internal compiler error: RTL check: expe cted code 'reg', have 'sign_extend' in rhs_regno, at rtl.h:1125 } ^ 0xd530c7 rtl_check_failed_code1(rtx_def const*, rtx_code, char const*, int, char const*) ../../src/trunk/gcc/rtl.c:773 0x6145f2 rhs_regno ../../src/trunk/gcc/rtl.h:1125 0x167748b rhs_regno ../../src/trunk/gcc/ree.c:388 0x167748b combine_reaching_defs ../../src/trunk/gcc/ree.c:703 0x16781e2 find_and_remove_re ../../src/trunk/gcc/ree.c:997 0x16781e2 rest_of_handle_ree ../../src/trunk/gcc/ree.c:1068 0x16781e2 execute ../../src/trunk/gcc/ree.c:1107 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. The gcc trunk has been bootstrapped with --enable-check=rtl switched on.
[Bug rtl-optimization/60131] [4.9 Regression] RTL check fail in rhs_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60131 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||law at gcc dot gnu.org Target Milestone|--- |4.9.0 Summary|RTL check fail in rhs_regno |[4.9 Regression] RTL check ||fail in rhs_regno --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- ree - Jeff.
[Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Does solaris properly align its stack on the entry of main? 0xb5aedf64 + 0x10 isn't aligned for paddd.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||jb at gcc dot gnu.org, ||jvdelisle at gcc dot gnu.org --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- This likely due to r185433. This fixed by the following patch --- ../_clean/libgfortran/io/write_float.def2014-01-21 08:30:57.0 +0100 +++ libgfortran/io/write_float.def2014-02-10 10:23:13.0 +0100 @@ -1215,8 +1211,8 @@ determine_en_precision (st_parameter_dt nbefore = 3 - nbefore; } int prec = f-u.real.d + nbefore; - if (dtp-u.p.current_unit-round_status != ROUND_UNSPECIFIED - dtp-u.p.current_unit-round_status != ROUND_PROCDEFINED) + /* if (dtp-u.p.current_unit-round_status != ROUND_UNSPECIFIED + dtp-u.p.current_unit-round_status != ROUND_PROCDEFINED) */ prec += 2 * len + 4; return prec; } For the following extended test write(*,(en15.2)) -.4 write(*,(rp,en15.2)) -.4 write(*,(rc,en15.2)) -.4 write(*,(rz,en15.2)) -.4 write(*,(rd,en15.2)) -.4 write(*,(en15.2)) -.6 write(*,(en15.1)) -.4 end before the patch, the output is -444.40E-03 -444.40E-03 -444.44E-03 -444.44E-03 -444.45E-03 -444.50E-03 -444.0E-03 after the patch, it is -444.44E-03 -444.44E-03 -444.44E-03 -444.44E-03 -444.45E-03 -444.46E-03 -444.4E-03 Regtesting in progress. Note that the block - if (dtp-u.p.current_unit-round_status != ROUND_UNSPECIFIED - dtp-u.p.current_unit-round_status != ROUND_PROCDEFINED) appears in several places in libgfortran/io/write_float.def and I fail to see the logic.
[Bug libgomp/60107] libgomp.c/pr58392.c etc. FAIL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60107 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Well, this isn't about main alignment (and, after all, main realigns the stack anyway), but about stack alignment upon entering pthread_create callbacks. If the Solaris libraries don't maintain 16-byte stack alignment, then either you could arrange to compile parts of libgomp with -mincoming-stack-boundary=2 (or -mstackrealign) on Solaris/i?86 32-bit. Or just make sure the default on Solaris is -mincoming-stack-boundary=2 or whatever the libraries do guarantee.
[Bug c/60129] Imprecise column numbers in NOTEs on discarding const qualifiers from pointer target type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60129 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-10 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Chengnian Sun from comment #0) Regarding the column numbers in the warnings, I am not sure whether they are expected as designed, as based on the warning message the user can still be able to infer which parameter such a warning is about. Most of the warnings in GCC were implemented before column numbers were available. Even now that there are, some of the location information necessary to print accurate column numbers is not available at the point of warning. GCC just needs more contributors willing to work on these issues.
[Bug c++/60132] New: C++11: lack of is_trivially_copy_constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60132 Bug ID: 60132 Summary: C++11: lack of is_trivially_copy_constructible Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: piotr.wyderski at gmail dot com The C++11 standard defines the content of type_traits to contain, among other things, template class T struct is_trivially_copy_constructible; GCC 4.8.2 does not provide this class. There was a related renaming mess in the late phase of the new standard definition process (has_trivlal_destructorT etc.), so IMHO this file needs a careful inspection to check its conformance to the final version. The bug has been found on Linux/x64 if this fact is of any imnportance.
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- With the patch in comment 2, the test gfortran.dg/edit_real_1.f90 fails for the outputs #5, 6, and 13 5 12.873E+03z 6 12.344E-06z 13999.999E+00z instead of the expected outputs 5 12.874E+03z 6 12.345E-06z 13 1.000E+03z
[Bug tree-optimization/60115] [4.8/4.9 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- The issue is that tree_could_trap_p, while handling case ARRAY_REF: base = TREE_OPERAND (expr, 0); if (tree_could_trap_p (base)) return true; if (TREE_THIS_NOTRAP (expr)) return false; return !in_array_bounds_p (expr); doesn't handle out-of-bound accesses via MEM_REF at all. case MEM_REF: if (TREE_CODE (TREE_OPERAND (expr, 0)) == ADDR_EXPR) return false; I have a fix.
[Bug regression/60133] New: [4.8 / 4.9 Regression] wrong multiarch name on aarch64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133 Bug ID: 60133 Summary: [4.8 / 4.9 Regression] wrong multiarch name on aarch64-linux-gnu Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Despite pinging this patch didn't see any review. The rather creative way to rename the libdir using a multilib configuration makes the 4.8 branch and trunk unusable on aarch64-linux-gnu on Debian and Ubuntu. patch and last ping at http://gcc.gnu.org/ml/gcc-patches/2014-01/msg02049.html
[Bug target/60074] g++.dg/vect/pr33426-ivdep-[34].cc FAIL on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60074 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Feb 10 11:09:21 2014 New Revision: 207652 URL: http://gcc.gnu.org/viewcvs?rev=207652root=gccview=rev Log: * g++.dg/vect/pr33426-ivdep-3.cc: Require vect_int_mult as well. * g++.dg/vect/pr33426-ivdep-4.cc: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-3.cc trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-4.cc
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- The regression reported in comment 3 disappears with the following patch --- ../_clean/libgfortran/io/write_float.def2014-01-21 08:30:57.0 +0100 +++ libgfortran/io/write_float.def2014-02-10 11:35:55.0 +0100 @@ -326,7 +322,7 @@ output_float (st_parameter_dt *dtp, cons for IEEE 754, this ought to be round to nearest, ties to even, corresponding to the Fortran ROUND='NEAREST'. */ case ROUND_PROCDEFINED: - case ROUND_UNSPECIFIED: + /* case ROUND_UNSPECIFIED: */ case ROUND_ZERO: /* Do nothing and truncation occurs. */ goto skip; case ROUND_UP: @@ -338,6 +334,7 @@ output_float (st_parameter_dt *dtp, cons goto skip; goto updown; case ROUND_NEAREST: + case ROUND_UNSPECIFIED: /* Round compatible unless there is a tie. A tie is a 5 with all trailing zero's. */ i = nafter + nbefore; @@ -1215,8 +1212,8 @@ determine_en_precision (st_parameter_dt nbefore = 3 - nbefore; } int prec = f-u.real.d + nbefore; - if (dtp-u.p.current_unit-round_status != ROUND_UNSPECIFIED - dtp-u.p.current_unit-round_status != ROUND_PROCDEFINED) + /* if (dtp-u.p.current_unit-round_status != ROUND_UNSPECIFIED + dtp-u.p.current_unit-round_status != ROUND_PROCDEFINED) */ prec += 2 * len + 4; return prec; } From the comment /* For processor defined and unspecified rounding we use snprintf to print the exact number of digits needed, and thus let snprintf handle the rounding. On system claiming support for IEEE 754, this ought to be round to nearest, ties to even, corresponding to the Fortran ROUND='NEAREST'. */ case ROUND_PROCDEFINED: case ROUND_UNSPECIFIED: case ROUND_ZERO: /* Do nothing and truncation occurs. */ I think it is wrong to handle ROUND_PROCDEFINED and ROUND_UNSPECIFIED as ROUND_ZERO.
[Bug regression/60133] [4.8/4.9 Regression] wrong multiarch name on aarch64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.3 Summary|[4.8 / 4.9 Regression] |[4.8/4.9 Regression] wrong |wrong multiarch name on |multiarch name on |aarch64-linux-gnu |aarch64-linux-gnu
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
Untested hack to generate somewhat smaller recog_* functions by dynamically
lowering the threshold if we'd see too big functions. With this patch we get
149 recog_* functions instead of 122, and largest number of lines in one
function decreases from more than 2 to about 9000.
--- genrecog.c.jj2014-01-03 11:40:29.0 +0100
+++ genrecog.c2014-02-10 12:21:32.547199720 +0100
@@ -1504,15 +1504,26 @@ simplify_tests (struct decision_head *he
that is generated. */
static int
-break_out_subroutines (struct decision_head *head, int initial)
+break_out_subroutines (struct decision_head *head, int initial, int threshold)
{
- int size = 0;
+ int size = 0, t;
struct decision *sub;
- for (sub = head-first; sub; sub = sub-next)
-size += 1 + break_out_subroutines (sub-success, 0);
+ if (head-first head-first-subroutine_number)
+return 1;
+
+ for (t = SUBROUTINE_THRESHOLD;
+ t SUBROUTINE_THRESHOLD / 2;
+ t -= SUBROUTINE_THRESHOLD / 10)
+{
+ size = 0;
+ for (sub = head-first; sub; sub = sub-next)
+size += 1 + break_out_subroutines (sub-success, 0, t);
+ if (size SUBROUTINE_THRESHOLD * 5)
+break;
+}
- if (size SUBROUTINE_THRESHOLD ! initial)
+ if (size threshold ! initial)
{
head-first-subroutine_number = ++next_subroutine_number;
size = 1;
@@ -2486,7 +2497,7 @@ process_tree (struct decision_head *head
factor_tests (head);
next_subroutine_number = 0;
- break_out_subroutines (head, 1);
+ break_out_subroutines (head, 1, SUBROUTINE_THRESHOLD);
find_afterward (head, NULL);
/* We run this after find_afterward, because find_afterward needs
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32096 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32096action=edit insn-recog.ii.bz2 Preprocessed source for -fpreprocessed insn-recog.ii -m32 -mtune=generic -march=pentiumpro -O2 -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common With --enable-checking=yes,rtl x86_64 compiler without -g it still takes 10 minutes to compile.
[Bug go/60134] New: runtime_unmarkspan panics with unaligned pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60134 Bug ID: 60134 Summary: runtime_unmarkspan panics with unaligned pointer Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: vogt at linux dot vnet.ibm.com (using git commit id e63988cca99cbbf6e5c459379309fe3359fe7c09) The test case convert.go fails with a panic in a panic on System/z: -- snip -- fatal error: markspan: unaligned pointer goroutine 1 [running]: runtime_dopanic ../../../libgo/runtime/panic.c:77 runtime_throw ../../../libgo/runtime/panic.c:115 runtime_unmarkspan ../../../libgo/runtime/mgc0.c:2452 __go_free ../../../libgo/runtime/malloc.goc:240 __go_panic ../../../libgo/runtime/go-panic.c:106 runtime_panicstring ../../../libgo/runtime/panic.c:134 __go_map_index ../../../libgo/runtime/go-map-index.c:92 reflect.canonicalize ../../../libgo/go/reflect/type.go:1782 reflect.toType ../../../libgo/go/reflect/type.go:1791 reflect.TypeOf ../../../libgo/go/reflect/type.go:1026 fmt..import ../../../libgo/go/fmt/print.go:643 __go_init_main /home/vogt/src/git/gcc/gcc/testsuite/go.test/test/convert.go:9 runtime_main ../../../libgo/runtime/proc.c:555 kickoff ../../../libgo/runtime/proc.c:232 -- snip -- It turns out that mgc0.c:runtime_unmarkspan() is called with a pointer that should be 16 byte aligned (wordsPerBitmapWord) but is actually only 8 byte aligned. The original pointer points to the stack variable Defer d in proc.c:runtime_main(). I guess the code should somehow enforce that Defer d is aligned to mgc0.c:wordsPerBitmapWord bytes, although I'm not sure about the right way to fix this. Note: Even though adding __attribute__ ((align(16))) for d fixes the problem for me, the test case still fails, but that is another issue that may or may not be platform specific. In any case I'll look into that and open another bug report if necessary.
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- I think the issue for that is probably ./cc1plus -quiet t.ii -O2 -ftime-report -m32 -Wdisabled-optimization ../../gcc/config/i386/sync.md: In function ‘int recog_102(rtx, rtx, int*)’: ../../gcc/config/i386/sync.md:518:1: warning: const/copy propagation disabled: 34779 basic blocks and 85328 registers [-Wdisabled-optimization] ../../gcc/config/i386/sync.md:518:1: warning: PRE disabled: 34779 basic blocks and 85328 registers [-Wdisabled-optimization] ../../gcc/config/i386/sync.md:518:1: warning: const/copy propagation disabled: 34779 basic blocks and 85328 registers [-Wdisabled-optimization] ../../gcc/config/i386/sync.md:518:1: warning: const/copy propagation disabled: 34536 basic blocks and 85329 registers [-Wdisabled-optimization] ... so we hit the self-imposed limits in cprop/gcse which then likely makes the compiler (the insn-recog part) very slow? As other parts of the compiler don't turn themselves off because of DF memory use at least the comment before this limit seems odd to me. (the compile still uses 1.7GB of ram for me). One issue is definitely the explicitely represented maximum set in lcm.c compute_available (and others - but that's used by both gcse and cprop).
[Bug debug/59992] [4.9 Regression] Compilation of insn-recog.c too slow due to var-tracking
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59992 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Bumping to --param max-gcse-memory=400 * 1024 * 1024 fixes that and we get (as expected from non-RTL checking -ftime-report) CPROP : 4.82 ( 3%) usr 0.57 ( 8%) sys 5.61 ( 3%) wall 112174 kB ( 4%) ggc PRE : 26.88 (16%) usr 0.78 (10%) sys 27.69 (16%) wall 4241 kB ( 0%) ggc TOTAL : 169.50 7.48 177.36 3130446 kB
[Bug tree-optimization/60115] [4.8 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 --- Comment #14 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Feb 10 13:51:23 2014 New Revision: 207656 URL: http://gcc.gnu.org/viewcvs?rev=207656root=gccview=rev Log: 2014-02-10 Richard Biener rguent...@suse.de PR tree-optimization/60115 * tree-eh.c (tree_could_trap_p): Unify TARGET_MEM_REF and MEM_REF handling. Properly verify that the accesses are not out of the objects bound. * gcc.dg/torture/pr60115.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr60115.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c
[Bug tree-optimization/60115] [4.8 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.8/4.9 Regression] wrong |[4.8 Regression] wrong code |code at -O3 on |at -O3 on x86_64-linux-gnu |x86_64-linux-gnu| Known to fail|4.9.0 | --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Let me have a look.
[Bug rtl-optimization/60131] [4.9 Regression] RTL check fail in rhs_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60131 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #2 from Jeffrey A. Law law at redhat dot com --- Mine. Fix ought to be trivial.
[Bug tree-optimization/59903] [4.8 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59903 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/60115] [4.8 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Feb 10 15:20:30 2014 New Revision: 207659 URL: http://gcc.gnu.org/viewcvs?rev=207659root=gccview=rev Log: 2014-02-10 Richard Biener rguent...@suse.de Backport from mainline 2014-01-30 Richard Biener rguent...@suse.de PR tree-optimization/59903 * tree-vect-loop.c (vect_transform_loop): Guard multiple-types check properly. * gcc.dg/torture/pr59903.c: New testcase. 2014-02-10 Richard Biener rguent...@suse.de PR tree-optimization/60115 * tree-eh.c (tree_could_trap_p): Unify TARGET_MEM_REF and MEM_REF handling. Properly verify that the accesses are not out of the objects bound. * gcc.dg/torture/pr60115.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59903.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr60115.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-eh.c branches/gcc-4_8-branch/gcc/tree-vect-loop.c
[Bug tree-optimization/59903] [4.8 Regression] ICE on valid code at -O3 on x86_64-linux-gnu (affecting trunk and 4.8.x)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59903 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Feb 10 15:20:30 2014 New Revision: 207659 URL: http://gcc.gnu.org/viewcvs?rev=207659root=gccview=rev Log: 2014-02-10 Richard Biener rguent...@suse.de Backport from mainline 2014-01-30 Richard Biener rguent...@suse.de PR tree-optimization/59903 * tree-vect-loop.c (vect_transform_loop): Guard multiple-types check properly. * gcc.dg/torture/pr59903.c: New testcase. 2014-02-10 Richard Biener rguent...@suse.de PR tree-optimization/60115 * tree-eh.c (tree_could_trap_p): Unify TARGET_MEM_REF and MEM_REF handling. Properly verify that the accesses are not out of the objects bound. * gcc.dg/torture/pr60115.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr59903.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr60115.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-eh.c branches/gcc-4_8-branch/gcc/tree-vect-loop.c
[Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org ---
Backporting this to 4.8 regresses
//-m32
FAIL: gcc.target/i386/pr49168-1.c scan-assembler movdqu[\t ]*%xmm[0-9]+,[^,]*
flt128_va:
.LFB0:
.cfi_startproc
movl4(%esp), %eax
movdqa 20(%esp), %xmm0
movlps %xmm0, (%eax)
movhps %xmm0, 8(%eax)
ret
expanding from
flt128_va (void * mem, __float128 d)
{
uint128_t _2;
;; basic block 2, loop depth 0
;;pred: ENTRY
_2 = VIEW_CONVERT_EXPRuint128_t(d_5(D));
MEM[(char * {ref-all})mem_3(D)] = _2;
return;
which doesn't end up using a UNSPEC_STOREU insn as on trunk but
(insn 8 7 0 2 (set (mem:V2SF (plus:SI (reg/v/f:SI 60 [ mem ])
(const_int 8 [0x8])) [0 MEM[(char * {ref-all})mem_3(D)]+8 S8
A8])
(vec_select:V2SF (subreg:V4SF (reg/v:TF 61 [ d ]) 0)
(parallel [
(const_int 2 [0x2])
(const_int 3 [0x3])
])))
/space/rguenther/src/svn/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr49168-1.c:10
-1
(nil))
[Bug middle-end/59990] [4.7/4.8 regression] incorrect memcpy optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59990 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- seems to be TARGET_SSE_TYPELESS_STORES tuning dependent (and that was changed on trunk for generic).
[Bug tree-optimization/60115] [4.8 Regression] wrong code at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60115 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug fortran/60060] [4.9 Regression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60060 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- wrapup_global_declarations looks like it's a no-op in LTO (DECL_DEFER_OUTPUT is always false). I am testing the following which avoids (re-)outputting debuginfo for local statics. Index: gcc/lto/lto-lang.c === --- gcc/lto/lto-lang.c (revision 207658) +++ gcc/lto/lto-lang.c (working copy) @@ -1082,17 +1082,11 @@ lto_write_globals (void) if (flag_wpa) return; - /* Record the global variables. */ - vectree lto_global_var_decls = vNULL; + /* Output debug info for global variables. */ varpool_node *vnode; FOR_EACH_DEFINED_VARIABLE (vnode) -lto_global_var_decls.safe_push (vnode-decl); - - tree *vec = lto_global_var_decls.address (); - int len = lto_global_var_decls.length (); - wrapup_global_declarations (vec, len); - emit_debug_global_declarations (vec, len); - lto_global_var_decls.release (); +if (!decl_function_context (vnode-decl)) + debug_hooks-global_decl (vnode-decl); } static tree
[Bug rtl-optimization/60131] [4.9 Regression] RTL check fail in rhs_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60131
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase for -O2:
struct A { short a; };
int **b;
unsigned long c;
bool foo ();
unsigned bar (unsigned i);
extern void baz () __attribute__((noreturn));
int *
test (unsigned x, struct A *y)
{
unsigned v;
if (foo () || y[x].a == -1)
{
c = bar (x);
return 0;
}
v = y[x].a;
if (v = 23)
baz ();
return b[v];
}
[Bug preprocessor/56824] [4.8 regression] pragma GCC diagnostic push/pop fail with GCC diagnostic ignored -Waggregate-return
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56824 --- Comment #12 from Magnus Reftel magnus.reftel at gmail dot com --- Works fine on trunk (tested version 96c7d4b1727c5f9ddcbb02fb69f727a0f2f3572e).
[Bug middle-end/52306] [4.8/4.9 regression] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 --- Comment #29 from Jeffrey A. Law law at gcc dot gnu.org --- Author: law Date: Mon Feb 10 16:25:44 2014 New Revision: 207662 URL: http://gcc.gnu.org/viewcvs?rev=207662root=gccview=rev Log: PR middle-end/52306 * reload1.c (emit_input_reload_insns): Do not create invalid RTL when changing the SET_DEST of a prior insn to avoid an input reload. PR middle-end-52306 * gcc.c-torture/compile/pr52306.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr52306.c Modified: trunk/gcc/ChangeLog trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/52306] [4.8 regression] ICE in cselib_record_set, at cselib.c:2158
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52306 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Summary|[4.8/4.9 regression] ICE in |[4.8 regression] ICE in |cselib_record_set, at |cselib_record_set, at |cselib.c:2158 |cselib.c:2158 --- Comment #30 from Jeffrey A. Law law at redhat dot com --- Fixed on the trunk.
[Bug c++/60135] New: add option to warn if ctor/conversion declared implicit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60135 Bug ID: 60135 Summary: add option to warn if ctor/conversion declared implicit Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mw_triad at users dot sourceforge.net explicit is a great tool for avoiding mistakes in the use of a class. Unfortunately, programmers must remember to use it, and there is not presently a mechanism to diagnose failure to do so. I would like to request that g++ add (1) a warning if a constructor or conversion operator is not declared explicit, and (2) some mechanism (e.g. an attribute) to silence this warning for a particular declaration, i.e. to annotate that a constructor or conversion operator is intended to be implicit. This would help to prevent forgetting to make such explicit when implicit behavior is not desired.
[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
||law at gcc dot gnu.org
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org ---
So, what happens is that we have:
(insn 39 38 41 5 (set (reg:QI 119)
(const_int 1 [0x1])) pr60116.c:17 93 {*movqi_internal}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
(insn 41 39 83 5 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 101 [ D.1460 ])
(const_int 0 [0]))) pr60116.c:18 3 {*cmpsi_ccno_1}
(nil))
(insn 83 41 42 5 (set (reg:SI 122 [ D.1465 ])
(zero_extend:SI (reg:QI 119))) 138 {*zero_extendqisi2}
(expr_list:REG_DEAD (reg:QI 119)
(nil)))
(the REG_DEAD on flags on the first insn supposedly comes from earlier
combining.
try_combine is then called on i3=insn83 and i2=insn39 and manages to combine
insn 83 into (set (reg:SI 122) (const_int 1 [0x1])).
The problem is when distribute_notes attempts to distribute the REG_DEAD
(reg:CCZ 17 flags) note from elim_i2=insn39 to i3=insn83.
[Bug target/59691] cilk-plus run failures on non-sse processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59691 --- Comment #10 from bviyer at gcc dot gnu.org --- Author: bviyer Date: Mon Feb 10 16:56:54 2014 New Revision: 207664 URL: http://gcc.gnu.org/viewcvs?rev=207664root=gccview=rev Log: Fix for PR target/59691. +2014-02-10 Balaji V. Iyer balaji.v.i...@intel.com + + PR target/59691 + * runtime/config/x86/os-unix-sysdep.c (__builtin_cpu_supports): New + function. + (restore_x86_fp_state): Added a check if the cpu supports the + instruction before emitting it. + (sysdep_save_fp_ctrl_state): Likewise. + Modified: trunk/libcilkrts/ChangeLog trunk/libcilkrts/runtime/config/x86/os-unix-sysdep.c
[Bug c++/59248] [4.8 regression] pointless -Wconversion warning with sizeof, take 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59248 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||jason at gcc dot gnu.org Known to work||4.9.0 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Works better with pre-4.9.
[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org --- And the place where we first change insn 39 is when simplifying the comparison that feeds it, in simplify_set: /* If we are setting CC0 or if the source is a COMPARE, look for the use of the comparison result and try to simplify it unless we already have used undobuf.other_insn. */ ... 6292 rtx pat = PATTERN (other_insn); 6293 undobuf.other_insn = other_insn; 6294 SUBST (*cc_use, tmp); So, is it a bug that we've kept REG_DEAD flags there in this case, or just distribute_notes shouldn't perform: /* If the register is being set at TEM, see if that is all TEM is doing. If so, delete TEM. Otherwise, make this into a REG_UNUSED note instead. Don't delete sets to global register vars. */ if ((REGNO (XEXP (note, 0)) = FIRST_PSEUDO_REGISTER || !global_regs[REGNO (XEXP (note, 0))]) reg_set_p (XEXP (note, 0), PATTERN (tem))) ... SET_INSN_DELETED (tem); Dunno how that could ever be safe if from_insn is the former i2 and i3 is a different insn and tem has bigger luid than from_insn. This code seems to be in there even in 3.2. Anyway, can somebody more familiar with this have a look?
[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Aha, checking=release is where the difference is evident.
[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- The difference I see is not that dramatic. float.c real10m5.540s user10m0.678s sys0m0.172s double.c: real7m54.983s user7m50.344s sys0m0.384s
[Bug target/59691] cilk-plus run failures on non-sse processors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59691 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jeffrey A. Law law at redhat dot com --- Fixed on trunk.
[Bug c/60114] Incorrect column number for -pedantic and -Wconversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60114 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Patch posted: http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00592.html, it will probably need to wait for GCC 5.0.
[Bug c/60114] Incorrect column number for -pedantic and -Wconversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60114 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target Milestone|4.9.0 |---
[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Started (expectably) with r146472 aka PR16202.
[Bug middle-end/60080] gcc.dg/vect/vect-nop-move.c FAILs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60080 --- Comment #3 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Mon Feb 10 18:19:01 2014 New Revision: 207668 URL: http://gcc.gnu.org/viewcvs?rev=207668root=gccview=rev Log: 2014-02-10 Bernd Edlinger bernd.edlin...@hotmail.de PR middle-end/60080 * cfgexpand.c (expand_asm_operands): Attach source location to ASM_INPUT rtx objects. * print-rtl.c (print_rtx): Check for UNKNOWN_LOCATION. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c trunk/gcc/print-rtl.c
[Bug rtl-optimization/60116] [4.8/4.9 Regression] wrong code at -Os on x86_64-linux-gnu in 32-bit mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60116 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Will do.
[Bug c++/60132] C++11: lack of is_trivially_copy_constructible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60132 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Yes, this is known and documented: http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Even if swapping an object with itself is well-defined it's a waste of time, so we shouldn't do it. There's a discussion happening now with the C++ library working group to resolve whether self-move-assignment is user error or supposed to be allowed (i.e. whether the debug mode assertion is ok or not)
[Bug rtl-optimization/60131] [4.9 Regression] RTL check fail in rhs_regno
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60131
--- Comment #4 from Jeffrey A. Law law at redhat dot com ---
The problem here is we first have the following candidate and defining insn:
gdb) p debug_rtx (cand-insn)
(insn 24 23 25 6 (set (reg:DI 0 ax [orig:100 D.2269 ] [100])
(zero_extend:DI (reg/v:SI 0 ax [orig:91 v ] [91]))) j.c:22 133
{*zero_extendsidi2}
(nil))
$13 = void
(gdb) p debug_rtx (curr_insn)
(insn 33 32 35 7 (set (reg/v:SI 0 ax [orig:91 v ] [91])
(sign_extend:SI (reg:HI 0 ax [orig:88 D.2271 ] [88]))) j.c:19 146
{extendhisi2}
(nil))
We eliminate insn 24 by changing insn 33 into:
(insn 33 32 35 7 (set (reg:DI 0 ax)
(zero_extend:DI (sign_extend:SI (reg:HI 0 ax [orig:88 D.2271 ] [88]
j.c:19 -1
(nil))
Later we call combine_reaching_defs to see if we can eliminate insn 33. It now
has an unexpected form and we trigger the checking fault.
[Bug c++/60113] Internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60113 --- Comment #8 from lmat dartmetrash at gmail dot com --- After I uploaded all these files, I thought, I probably should have compressed that -- I bet the ratio would have been really good... Unfortunately, ubuntu repos don't hold 4.7, etc. (sigh). I'll upgrade my compiler. Thanks for looking!
[Bug fortran/60060] [4.9 Regression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60060 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- The ICE is gone with the patch in comment 4 without regression. However on darwin I still get the warnings reported in comment 0. Although this could be hidden with the suitable dg-prune-output, I'ld prefer to see this fixed also.
[Bug c/60136] New: indexing an 8-element array with a long long results in bad results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60136 Bug ID: 60136 Summary: indexing an 8-element array with a long long results in bad results Product: gcc Version: 4.5.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: daniel.hussey at nist dot gov My compile command is: gcc program.c -o test -L. -lcfitsio -lm I was indexing an 8-element double array with a long long integer. When converting the result to a string (sprintf of printf) the result was garbage. When used in computation, the correct value was used.
[Bug c/60101] [4.7/4.8/4.9 Regression] Long compile times when mixed complex floating point datatypes are used in lengthy expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60101 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Unassigning for now.
[Bug fortran/60060] [4.9 Regression] lto1: internal compiler error: in add_AT_specification, at dwarf2out.c:4096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60060 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #0) warning: invalid DWARF generated by the compiler: DIE 0x01f0 has multiple AT_calling_convention attributes in '/var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccLHCwpM.ltrans0.ltrans. o'. (In reply to Dominique d'Humieres from comment #5) The ICE is gone with the patch in comment 4 without regression. However on darwin I still get the warnings reported in comment 0. The calling convention should be (except on sh, cf. sh/sh.c's TARGET_DWARF_CALLING_CONVENTION) be always DW_CC_normal - which is not emitted as DWARF symbol. The only exception is Fortran's MAIN__ function, which is set to DW_CC_program. I wonder whether you see twice DW_CC_program or some other DW_CC_*. You could try readelf to find out which AT_calling_convention are generated.
[Bug c/60136] indexing an 8-element array with a long long results in bad results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60136 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-10 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Please provide a testcase. http://gcc.gnu.org/bugs/
[Bug target/60137] New: Code fails with -mcpu=power8 -O3 -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60137
Bug ID: 60137
Summary: Code fails with -mcpu=power8 -O3 -mno-vsx
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: meissner at gcc dot gnu.org
Created attachment 32097
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32097action=edit
Program to show the problem
If you disable VSX but enable vectorization and power8 code generation, the
compiler returns a cannot split insn error:
foo.c: In function ‘init_reg_sets_1’:
foo.c:10:1: error: could not split insn
}
^
(insn:TI 730 812 622 (set (reg:V16QI 6 6 [orig:378 vect_patt_115.53 ] [378])
(mem/c:V16QI (reg:DI 9 9) [0 S16 A128])) 1080 {*altivec_movv16qi}
(expr_list:REG_DEAD (reg:DI 9 9)
(nil)))
foo.c:10:1: internal compiler error: in final_scan_insn, at final.c:2963
0x8ef868 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/meissner/fsf-src/trunk/gcc/rtl-error.c:109
0x6ed23d final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
/home/meissner/fsf-src/trunk/gcc/final.c:2963
0x6ed661 final(rtx_def*, _IO_FILE*, int)
/home/meissner/fsf-src/trunk/gcc/final.c:2024
0x6ed889 rest_of_handle_final
/home/meissner/fsf-src/trunk/gcc/final.c:4438
0x6ed889 execute
/home/meissner/fsf-src/trunk/gcc/final.c:4513
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.
[Bug target/60137] Code fails with -mcpu=power8 -O3 -mno-vsx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60137 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-02-10 Ever confirmed|0 |1 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Note, it will work if you use either -mcpu=power7 -mno-vsx or -mcpu=power8 -mno-vsx -mno-altivec.
[Bug target/60138] New: superh single/double precision fpu mode setting is backwards and unusable
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60138 Bug ID: 60138 Summary: superh single/double precision fpu mode setting is backwards and unusable Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx The sh target switches between single and double precision fpu modes (needed for operating on floats and doubles, respectively) via loading the fpscr from a global variable array __fpscr_values[2]. At times in the past this array has been provided by libgcc; it seems it's currently expected that libc provides it. Each time gcc needs to perform a floating point operation and does not know the current mode, it loads the full fpscr value, clobbering any non-default rounding mode (set by fesetround), exception flags (set by floating point operations), and other state. This makes it impossible to implement working fenv.h API on sh; while glibc implements these functions, they don't work, because gcc immediately clobbers the fpscr before performing the next floating point operation. It should be noted that __fpscr_values is non-const, and in fact I've found some software that writes non-default bits into this array so that it can use non-default settings (particular, flush-denormals-to-zero mode) without them getting clobbered (since gcc will happily reload whatever you put in this array). I suspect the original intent was that the fenv.h functions could also do this. However, that's utterly broken since __fpscr_values is global and floating point environment is supposed to be thread-local. To fix this, the ridiculous hack of loading the value for fpscr from __fpscr_values and directly writing to the fpscr should be removed, and replaced with a read-modify-write cycle (read old fpscr, set/mask precision bit, and write back to fpscr). Naturally this will hurt performance but the current code is simply non-working and needs to be fixed. One could move __fpscr_values to TLS, but given that TLS access does not seem to perform that well on sh, I suspect that's slower than the read-modify-write cycle on fpscr.
[Bug fortran/49636] [F03] ASSOCIATE construct confused with slightly complicated case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49636 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #4 from Paul Thomas pault at gcc dot gnu.org --- Created attachment 32098 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32098action=edit A fix for this problem I am sure that this trick will fix pr57019 too. This latter is claimed to be a regression but I am sure that it never worked :-) Nonetheless, I will take advantage of the regression label! I will work on it tomorrow night. By the way, this patch regtests OK on trunk. I have to make sure that substrings of character arrays work OK with ASSOCIATE. Thanks for the heads-up Dominique! Cheers Paul
[Bug c/60103] Spurious -Wsequence-point warning with -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60103 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-10 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I think the warning isn't spurious and should be output even with -O0. But the fact that we output the warning with -O is IMHO pure coincidence, we do it only because we fold away the useless || 0. So the bug is probably in verify_sequence_points. Note that C11 still has the notion of sequence point; it's C++11 where it was renamed to sequenced after/before.
[Bug target/57936] ICE in rs6000_secondary_reload_inner:15144, type = load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936 --- Comment #2 from Alan Modra amodra at gmail dot com --- No, cancel comment #1, I was fooled by version skew between the unpatched and the patched compiler. The testcase doesn't ICE on recent versions of gcc.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #51 from Denis Kolesnik denis.v.koles...@safe-mail.net --- I will set as unconfirmed each time it will be changed, because I have no ability to download from internet the version 4.6.1 from MinGW official source(and the version I have now on my DVD could be contaminated with a virus). Maybe you are right and there is no bug. I could make diplomacy even if there is a bug but not in key questions of my politic views. You also should acknowledge your mistakes. I do if I'm wrong, why you do not do the same? It does not makes you bad, just shows you, that you should work on yourself as I do and I do a lot of mistakes, which I acknowledge. Sorry also for uncensored words, but if you will demand I will search something that is unspoken now... There is a version 4.6.1 from google, I will try it now and if there is no bug I resolve this as invalid, but again not to forget about my key views.
[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927 --- Comment #8 from Richard Henderson rth at gcc dot gnu.org --- (In reply to Kai Tietz from comment #7) One side-note I have about this patch. Due this allow drap-register for x64, we seem to need to enable eax_live for this target, too. See in ix86_expand_prologue the lines ... if (!TARGET_64BIT_MS_ABI) eax_live = ix86_eax_live_at_start_p (); ... In theory it shouldn't matter. Unlike the unix 64-bit abi, EAX is never live for any w64 abi. On the other hand, removing the condition shouldn't hurt either, making the code less confusing.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #52 from Andrew Pinski pinskia at gcc dot gnu.org --- I think you will find that you need to open the file in binary mode and that might help you out. And that the char is 8bit characters so the you need to look up the encoding format for UTF-8.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Denis Kolesnik denis.v.koles...@safe-mail.net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #53 from Denis Kolesnik denis.v.koles...@safe-mail.net --- I will try to not such google services, because I'm not sure that my conditions will be respected and I will search guaranties. But while a character is 8bit what does it change? All russian letters, that are used in current russian language are coded in the similar maner?!
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 --- Comment #54 from Denis Kolesnik denis.v.koles...@safe-mail.net --- please do not close this issue untill I will have the abilitz to prove whether it is a bug or not.
[Bug rtl-optimization/42863] [4.7/4.8/4.9 Regression] with auto increments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42863 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #9 from Jeffrey A. Law law at redhat dot com --- AFAICT the current trunk generates code that is as good as or better than gcc-4.4. The redundant moves/tests are gone. And the load of dst out of the stack is deferred until we know we need it. There's a tiny bit of register shuffling in one arm of a conditional, but it's offset by avoid it in another conditional. Overall, the trunk code is IMHO as good as or better than gcc-4.4. There are no plans to identify what changes caused the improved code generation. Obviously with no plans to identify the changes, there are no plans to backport the changes to older release branches.
[Bug c++/59598] very simple code using file open for read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59598 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #55 from Andrew Pinski pinskia at gcc dot gnu.org --- Seriously this bug report is out of hand. First let me say this: what do you think GCC is doing wrong? If you want report a new bug as this bug is full of many different bugs in your code; don't reopen this bug. Please when you open a new one explain what you think GCC is doing wrong and provide all the needed data files (which you are missing right now). Second the library functions like fopen and fgetc are not provided by GCC but by your libc vendor (in the case of mingw, mingw and to some extend even Microsoft). So if this code is not working due to fopen/fgetc then it is not a bug in GCC. Note I see at least one bug in your code, fgetc returns an int type and EOF is -1 in int as 0xff is a valid character (not in UTF-8 though). It might be the cause of the bug in the first place.
[Bug c/60139] New: Imprecise column number for -pedantic on non-computable initializer element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60139
Bug ID: 60139
Summary: Imprecise column number for -pedantic on
non-computable initializer element
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
I have two questions regarding the warnings by gcc on array initializers.
1) the column numbers in the warnings by -pedantic are not precise.
2) the warning message says the warning is enabled by default, but in fact the
warning is only enabled with -pedantic. When I use the command
$gcc-trunk -c -std=c89 non-constant-initializers.c
then no warning is emitted.
$: cat non-constant-initializers.c
void fn() {
int a1;
int *p1 = a1;
int** array[5] =
{p1,
(void*)0, (void*)0, (void*)0, p1};
}
$: gcc-trunk -c -std=c89 -pedantic non-constant-initializers.c
non-constant-initializers.c: In function ‘fn’:
non-constant-initializers.c:5:3: warning: initializer element is not computable
at load time [enabled by default]
{p1,
^
non-constant-initializers.c:6:9: warning: initializer element is not computable
at load time [enabled by default]
(void*)0, (void*)0, (void*)0, p1};
^
$: gcc-trunk -c -std=c89 non-constant-initializers.c
$:
$:
[Bug lto/59468] [4.9 Regression] ICE on invalid C++ code with LTO in gimple_get_virt_method_for_binfo, at gimple-fold.c:3224
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59468 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- The ICE is already fixed by my reorg of gimple_get_virt_method_for_vtable. I am experimenting with patch that adds a warning. Honza
[Bug inline-asm/60140] New: Cross compiler i386 atom fails - divtf3.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60140 Bug ID: 60140 Summary: Cross compiler i386 atom fails - divtf3.c Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: shenhan at google dot com CC: llozano at google dot com, wmi at google dot com Created attachment 32099 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32099action=edit test case Note - this only fails for google/gcc-4_8 branch. Compilation failure while build cross compiler for i386 atom. To reproduce - configure: ~/gcc.git/configure --disable-bootstrap --enable-languages='c,c++' --disable-multilib --disable-libatomic --disable-libmudflap --disable-libssp --enable-libgomp --enable-__cxa_atexit --enable-checking=release --disable-libquadmath --disable-libitm --enable-esp --with-arch=atom --with-tune=atom --enable-frame-pointer Build - make -j40 Compile a testcase - ./gcc/xgcc -B./gcc -O2 -fpic -c -m32 ./divtf3.pp.c Output - /divtf3.pp.c:64:1194: error: ‘asm’ operand has impossible constraints Note divtf3.pp.c is actually a preprocessed file from libgcc/soft-fp/divtf3.c.
[Bug target/57936] ICE in rs6000_secondary_reload_inner:15144, type = load
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57936 --- Comment #3 from Alan Modra amodra at gmail dot com --- The testcase doesn't ICE since 206639. That wasn't an rs6000 patch so we probably still have the underlying issue in the rs6000 backend.
[Bug rtl-optimization/60141] New: ICE in i386.c distance_non_agu_define_in_bb
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60141
Bug ID: 60141
Summary: ICE in i386.c distance_non_agu_define_in_bb
Product: gcc
Version: 4.8.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: shenhan at google dot com
CC: llozano at google dot com, tejohnson at google dot com
This only fails for google/gcc-4_8
To reproduce -
configure:
~/gcc.git/configure --disable-bootstrap --enable-languages='c,c++'
--disable-multilib --disable-libatomic --disable-libmudflap
--disable-libssp --enable-libgomp --enable-__cxa_atexit
--enable-checking=release --disable-libquadmath --disable-libitm
--enable-esp --with-arch=atom --with-tune=atom --enable-frame-pointer
Build -
make -j40
Compile a testcase -
./gcc/xgcc -B./gcc -g -O2 -fpic -c -m32 ~/SROA.pp.cpp
Output -
SROA.cpp: In member function ‘void
{anonymous}::AllocaPartitioning::UseBuilder::operator()()’:
SROA.cpp:873:3: internal compiler error: Segmentation fault
0x8d0baf crash_signal
../../../gcc.git/gcc/toplev.c:346
0xa798c8 distance_non_agu_define_in_bb
../../../gcc.git/gcc/config/i386/i386.c:17506
0xa79cad distance_non_agu_define
../../../gcc.git/gcc/config/i386/i386.c:17564
0xa79cad ix86_lea_outperforms
../../../gcc.git/gcc/config/i386/i386.c:17730
0xb8e6ca output_89
../../../gcc.git/gcc/config/i386/i386.md:2152
0x72a5c3 final_scan_insn(rtx_def*, _IO_FILE*, int, int, int*)
../../../gcc.git/gcc/final.c:2895
0x72ae84 final(rtx_def*, _IO_FILE*, int)
../../../gcc.git/gcc/final.c:1986
0x72b46d rest_of_handle_final
../../../gcc.git/gcc/final.c:4432
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.
Debugging shows that in distance_non_agu_define_in_bb (i386.c),
BLOCK_FOR_INSN(start) returns zero, which caused this ICE.
A preliminary bisecting in google/gcc-4_8 shows that the follow CL introduces
this ICE. (So I cc'ed Teresa Johnson)
commit 907fca49eae2da51a328eb192c691cc24f69e6af
Author: tejohnson tejohnson@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Mon Dec 2 18:28:19 2013 +
Backport the last few fixes for -freorder-blocks-and-partition from
trunk to google/4_8: r204985, r205057 and r205243
r204985 | tejohnson | 2013-11-18 14:38:51 -0800 (Mon, 18 Nov 2013) | 15
lines
This patch fixes an lto profiledbootstrap failure with
-freorder-blocks-and-partition enabled. Currently compgotos
is the only pass that goes into cfglayout mode after bb reordering,
which is undesireable (and in the case of
-freorder-blocks-and-partition
can cause illegal partitioning) because of the optimizations performed
on the cfg when going into cfglayout mode. Moved compgoto before
bb reordering to avoid these problems.
2013-11-18 Teresa Johnson tejohn...@google.com
* gcc/cfgrtl.c (cfg_layout_initialize): Assert if we
try to go into cfglayout after bb reordering.
* gcc/passes.def: Move compgotos before bb reordering
since it goes into cfglayout.
r205057 | tmsriram | 2013-11-19 14:12:21 -0800 (Tue, 19 Nov 2013) | 7
lines
Emit a label for the split cold function part. Label name is formed by
suffixing the original function name with cold.
Patch tested for bootstrap on all default languages on x86_64 and
regression testsuite checked for parity with RUNTESTFLAGS -m32 and m64.
2013-11-19 Sriraman Tallam tmsri...@google.com
* final.c (final_scan_insn): Emit a label for the split
cold function part. Label name is formed by suffixing
the original function name with cold.
2013-11-19 Sriraman Tallam tmsri...@google.com
* gcc.dg/tree-prof/cold_partition_label.c: New testcase.
r205243 | tejohnson | 2013-11-21 20:16:47 -0800 (Thu, 21 Nov 2013) | 6
lines
2013-11-21 Teresa Johnson tejohn...@google.com
* cfgcleanup.c (outgoing_edges_match): Walk up past note instructions
not understood by old_insns_match_p.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/google/gcc-4_8@205594
138bc75d-0d04-0410-961f-82ee72b054a4
[Bug target/59927] [4.9 Regression] ICE sorry, unimplemented: ms_abi attribute requires -maccumulate-outgoing-args or subtarget optimization implying it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59927 --- Comment #9 from Richard Henderson rth at gcc dot gnu.org --- Author: rth Date: Tue Feb 11 01:12:38 2014 New Revision: 207677 URL: http://gcc.gnu.org/viewcvs?rev=207677root=gccview=rev Log: PR target/59927 * calls.c (expand_call): Don't double-push for reg_parm_stack_space. * config/i386/i386.c (init_cumulative_args): Remove sorry for 64-bit ms-abi vs -mno-accumulate-outgoing-args. (ix86_expand_prologue): Unconditionally call ix86_eax_live_at_start_p. * config/i386/i386.h (ACCUMULATE_OUTGOING_ARGS): Fix comment with respect to ms-abi. Modified: trunk/gcc/ChangeLog trunk/gcc/calls.c trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.h
[Bug target/40454] [4.7/4.8/4.9 regression] zlib is about 20% slower when compiled with GCC 4.4.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40454 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |WONTFIX --- Comment #21 from Jeffrey A. Law law at redhat dot com --- Without an in-depth analysis from someone with real hardware there's simply nothing we're going to be able to do here. Sadly we don't have good tools in the m68k world like valgrind, oprofile, etc which would allow for a good in-depth analysis of what's going on. And I've found performance testing within the anarym emulator to be too variable to be of any value. I'm closing as WONTFIX as that's the sad, unfortunate reality.
