[Bug c++/63356] Compilation failure where clang does not have problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63356 --- Comment #13 from fiesh at zefix dot tv --- Are there any news on this bug? At least for us, this keeps production code from being able to work with any boost 1.55, which is becoming an increasingly bigger issue.
[Bug target/63321] [SH] Unused T bit result of shll / shlr insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63321
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
The shll/shlr insns effectively perform two operations:
T = zero_extract single bit 0 / 31 from reg
reg = reg 1 / reg 1.
The other shift insns as in comment #5 perform only a single operation. Thus
those two things should be probably handled slightly differently.
With my current patchset for handling single bit zero_extract (PR 64345), code
like
void test4 (unsigned int x, unsigned int* y)
{
y[0] = (x 0) 1;
y[1] = (x 1) 1;
y[2] = (x 2) 1;
y[3] = (x 3) 1;
}
results in the following insns right after the combine pass:
(insn 7 4 8 2 (set (reg:SI 171 [ D.1733 ])
(and:SI (reg/v:SI 169 [ x ])
(const_int 1 [0x1]))) sh_tmp.cpp:432 115 {*andsi_compact}
(nil))
...
(insn 10 9 11 2 (parallel [
(set (reg:SI 173 [ D.1733 ])
(zero_extract:SI (reg/v:SI 169 [ x ])
(const_int 1 [0x1])
(const_int 1 [0x1])))
(clobber (reg:SI 147 t))
]) sh_tmp.cpp:433 409 {any_treg_expr_to_reg}
(expr_list:REG_UNUSED (reg:SI 147 t)
(nil)))
...
(insn 13 12 14 2 (parallel [
(set (reg:SI 175 [ D.1733 ])
(zero_extract:SI (reg/v:SI 169 [ x ])
(const_int 1 [0x1])
(const_int 2 [0x2])))
(clobber (reg:SI 147 t))
]) sh_tmp.cpp:434 409 {any_treg_expr_to_reg}
(expr_list:REG_UNUSED (reg:SI 147 t)
(nil)))
...
(insn 16 15 17 2 (parallel [
(set (reg:SI 177 [ D.1733 ])
(zero_extract:SI (reg/v:SI 169 [ x ])
(const_int 1 [0x1])
(const_int 3 [0x3])))
(clobber (reg:SI 147 t))
]) sh_tmp.cpp:435 409 {any_treg_expr_to_reg}
(expr_list:REG_UNUSED (reg:SI 147 t)
(expr_list:REG_DEAD (reg/v:SI 169 [ x ])
(nil
Those pseudo-insns are then split into tst/bld/movt/movrt sequences in the
split1 pass. If a special shll/shlr pass is done right after combine and
before split1, it's possible to identify potential good shll/shlr sequences
rather easily and rewrite the code to use shll/shlr instead.
[Bug target/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 --- Comment #13 from Chen Gang gang.chen.5i5j at gmail dot com --- For gcc version 5.0.0 20150109 (experimental) (GCC), can not find this issue again. So at present, we can close it.
[Bug libstdc++/64560] New: [5 Regression] building libstdc++ with -fno-rtti fails in new cxx11-shim-facets.cc file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64560 Bug ID: 64560 Summary: [5 Regression] building libstdc++ with -fno-rtti fails in new cxx11-shim-facets.cc file Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Someone on IRC pointed out that the build fails when configuring with --enable-cxx-flags=-fno-rtti In file included from /home/jwakely/src/gcc/libstdc++-v3/src/c++11/cow-shim_facets.cc:35:0: /home/jwakely/src/gcc/libstdc++-v3/src/c++11/cxx11-shim_facets.cc: In member function ‘const std::locale::facet* std::locale::facet::_M_cow_shim(const std::locale::id*) const’: /home/jwakely/src/gcc/libstdc++-v3/src/c++11/cxx11-shim_facets.cc:772:51: error: ‘dynamic_cast’ not permitted with -fno-rtti if (auto* p = dynamic_castconst __shim*(this)) ^
[Bug libstdc++/64560] [5 Regression] building libstdc++ with -fno-rtti fails in new cxx11-shim-facets.cc file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64560 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-11 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/58256] gcc for h8300 internal compiler error: in maybe_record_trace_start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58256 Chen Gang gang.chen.5i5j at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Chen Gang gang.chen.5i5j at gmail dot com --- For gcc version 5.0.0 20150109 (experimental) (GCC), can not find this issue again. So at present, we can mark it as FIXED
[Bug libgcj/34574] wait() call hangs in _Jv_CondWait taking the monitor with it causing the application to hang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34574 --- Comment #4 from Igor Pashev pashev.igor at gmail dot com --- I can reploduce it with Debian/amd64 and gcc4.9: Thread 3 (Thread 0x7f43f8764700 (LWP 16318)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f445d4f74b9 in _L_lock_909 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x7f445d4f72e0 in __GI___pthread_mutex_lock (mutex=0x7f4461280ea0) at ../nptl/pthread_mutex_lock.c:79 #3 0x7f445ef93684 in _Jv_MutexLock(_Jv_Mutex_t*) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #4 0x7f445ef8851c in _Jv_MonitorEnter () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #5 0x004030fd in JvSynchronize::JvSynchronize (this=0x7f43f8763de0, o=@0x6057e0: 0x7f44612cbc60) at /usr/include/c++/4.9/gcj/cni.h:99 #6 0x00402f25 in env_test::foo () at TestJVSynchronise19thDec.cc:18 #7 0x00402ef3 in env_test.run()void () at env_test.java:8 #8 0x00402430 in WorkerThread.run()void () at ThreadPool.java:154 #9 0x7f445ef8c16b in _Jv_ThreadRun(java::lang::Thread*) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #10 0x7f445ef93ff7 in ?? () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #11 0x7f445f7bb748 in ?? () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #12 0x7f445d4f50a4 in start_thread (arg=0x7f43f8764700) at pthread_create.c:309 #13 0x7f445cc02ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7f43f7f63700 (LWP 16319)): #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135 #1 0x7f445d4f74b9 in _L_lock_909 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x7f445d4f72e0 in __GI___pthread_mutex_lock (mutex=0x7f4461280ea0) at ../nptl/pthread_mutex_lock.c:79 #3 0x7f445ef93684 in _Jv_MutexLock(_Jv_Mutex_t*) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #4 0x7f445ef8851c in _Jv_MonitorEnter () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #5 0x004030fd in JvSynchronize::JvSynchronize (this=0x7f43f7f62de0, o=@0x6057e0: 0x7f44612cbc60) at /usr/include/c++/4.9/gcj/cni.h:99 #6 0x00402f25 in env_test::foo () at TestJVSynchronise19thDec.cc:18 #7 0x00402ef3 in env_test.run()void () at env_test.java:8 #8 0x00402430 in WorkerThread.run()void () at ThreadPool.java:154 #9 0x7f445ef8c16b in _Jv_ThreadRun(java::lang::Thread*) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #10 0x7f445ef93ff7 in ?? () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #11 0x7f445f7bb748 in ?? () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #12 0x7f445d4f50a4 in start_thread (arg=0x7f43f7f63700) at pthread_create.c:309 #13 0x7f445cc02ccd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7f44612ef740 (LWP 16118)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f445ef9380b in _Jv_CondWait(_Jv_ConditionVariable_t*, _Jv_Mutex_t*, long long, int) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #2 0x7f445ef88ab5 in void java::lang::Object::wait(long long, int) () from /usr/lib/x86_64-linux-gnu/libgcj.so.15 #3 0x00402bd5 in Done.waitDone()void () at ThreadPool.java:213 #4 0x00402a2e in ThreadPool.complete()void () at ThreadPool.java:100 #5 0x0040305f in main (argc=1, argv=0x7fff5fac12e8) at TestJVSynchronise19thDec.cc:39
[Bug ipa/64559] ICE at -Os on x86_64-linux-gnu in remove_unreachable_nodes, at ipa.c:582
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64559 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-01-11 CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r219108.
[Bug fortran/37131] inline matmul for small matrix sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #17 from Thomas Koenig tkoenig at gcc dot gnu.org --- I'm currently working on that. Basically, it means adding a flexible scalarizer in the front end passes. I think I have some idea on how to go about this.
[Bug libstdc++/64560] [5 Regression] building libstdc++ with -fno-rtti fails in new cxx11-shim-facets.cc file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64560
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org ---
--- a/libstdc++-v3/src/c++11/cxx11-shim_facets.cc
+++ b/libstdc++-v3/src/c++11/cxx11-shim_facets.cc
@@ -768,9 +768,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
using namespace __facet_shims;
+#if __cpp_rtti
// If this is already a shim just use its underlying facet.
if (auto* p = dynamic_castconst __shim*(this))
return p-_M_get();
+#endif
if (which == numpunctchar::id)
return new numpunct_shimchar{this};
[Bug fortran/58023] [F03] ICE on invalid with bad PPC declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023 --- Comment #6 from janus at gcc dot gnu.org --- Author: janus Date: Sun Jan 11 19:13:24 2015 New Revision: 219439 URL: https://gcc.gnu.org/viewcvs?rev=219439root=gccview=rev Log: 2015-01-11 Janus Weil ja...@gcc.gnu.org PR fortran/58023 * resolve.c (resolve_fl_derived0): Set error flag if problems with the interface of a procedure-pointer component were detected. 2015-01-11 Janus Weil ja...@gcc.gnu.org PR fortran/58023 * gfortran.dg/proc_ptr_comp_42.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_42.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/58023] [F03] ICE on invalid with bad PPC declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58023 --- Comment #7 from janus at gcc dot gnu.org --- I have finally committed the patch in comment 2 (sorry that it took so long). The ICE on comment 0 is still there, but for consistency one should do a bit more than shown in comment 5. Will take care of that next.
[Bug fortran/64508] [F03] interface check missing for procedure pointer component as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64508 --- Comment #2 from janus at gcc dot gnu.org --- Author: janus Date: Sun Jan 11 17:31:22 2015 New Revision: 219431 URL: https://gcc.gnu.org/viewcvs?rev=219431root=gccview=rev Log: 2015-01-11 Janus Weil ja...@gcc.gnu.org PR fortran/64508 * interface.c (compare_parameter): Interface check for procedure-pointer component as actual argument. 2015-01-11 Janus Weil ja...@gcc.gnu.org PR fortran/64508 * gfortran.dg/proc_ptr_comp_41.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_41.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug target/63724] [AArch64] Inefficient immediate expansion and hoisting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63724 --- Comment #4 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Sun Jan 11 18:36:42 2015 New Revision: 219433 URL: https://gcc.gnu.org/viewcvs?rev=219433root=gccview=rev Log: gcc/ 2015-01-11 Yvan Roux yvan.r...@linaro.org Backport from trunk r217362, r217546. 2014-11-14 Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/63724 * config/aarch64/aarch64.c (aarch64_expand_mov_immediate): Split out numerical immediate handling to... (aarch64_internal_mov_immediate): ...this. New. (aarch64_rtx_costs): Use aarch64_internal_mov_immediate. (aarch64_mov_operand_p): Relax predicate. * config/aarch64/aarch64.md (movmode:GPI): Do not expand CONST_INTs. (*movsi_aarch64): Turn into define_insn_and_split and new alternative for 'n'. (*movdi_aarch64): Likewise. 2014-11-11 James Greenhalgh james.greenha...@arm.com * config/aarch64/aarch64-simd.md (aarch64_simd_bslmode_internal): Remove float cases, canonicalize. (aarch64_simd_bslmode): Add gen_lowpart expressions where we are punning between float vectors and integer vectors. gcc/testsuite 2015-01-11 Yvan Roux yvan.r...@linaro.org Backport from trunk r217362. 2014-11-11 James Greenhalgh james.greenha...@arm.com * gcc.target/aarch64/vbslq_f64_1.c: New. * gcc.target/aarch64/vbslq_f64_2.c: Likewise. * gcc.target/aarch64/vbslq_u64_1.c: Likewise. * gcc.target/aarch64/vbslq_u64_2.c: Likewise. Added: branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/vbslq_f64_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/vbslq_f64_2.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/vbslq_u64_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/aarch64/vbslq_u64_2.c Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64-simd.md branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64.c branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64.md branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro
[Bug fortran/64508] [F03] interface check missing for procedure pointer component as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64508 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from janus at gcc dot gnu.org --- Actually closing.
[Bug fortran/64508] [F03] interface check missing for procedure pointer component as actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64508 --- Comment #3 from janus at gcc dot gnu.org --- Fixed with r219431. Closing.
[Bug tree-optimization/64563] New: ICE with -Wall -Wextra at -Os and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64563
Bug ID: 64563
Summary: ICE with -Wall -Wextra at -Os and above on
x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled using the current gcc trunk with
-Wall -Wextra at -Os and above on x86_64-linux-gnu in both 32-bit and 64-bit
modes.
It is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20150111 (experimental) [trunk revision 219429] (GCC)
$
$ gcc-trunk -Os -c small.c
$ gcc-4.9 -Wall -Wextra -Os -c small.c
small.c: In function ‘fn1’:
small.c:7:14: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
d = b = (a != (e | 4294967288UL));
^
$
$ gcc-trunk -Wall -Wextra -Os -c small.c
small.c: In function ‘fn1’:
small.c:7:14: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
d = b = (a != (e | 4294967288UL));
^
small.c:5:1: internal compiler error: Segmentation fault
fn1 ()
^
0xa9896f crash_signal
../../gcc-trunk/gcc/toplev.c:372
0xce9a44 contains_struct_check(tree_node const*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-trunk/gcc/tree.h:3128
0xce9a44 vrp_val_is_min
../../gcc-trunk/gcc/tree-vrp.c:241
0xcf0094 vrp_evaluate_conditional
../../gcc-trunk/gcc/tree-vrp.c:7550
0xd06454 fold_predicate_in
../../gcc-trunk/gcc/tree-vrp.c:9958
0xd06454 vrp_fold_stmt
../../gcc-trunk/gcc/tree-vrp.c:10001
0xc2c3d3 substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../gcc-trunk/gcc/tree-ssa-propagate.c:1148
0x10ad7e7 dom_walker::walk(basic_block_def*)
../../gcc-trunk/gcc/domwalk.c:188
0xc2bcf0 substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool)
../../gcc-trunk/gcc/tree-ssa-propagate.c:1236
0xd033f4 vrp_finalize
../../gcc-trunk/gcc/tree-vrp.c:10189
0xd033f4 execute_vrp
../../gcc-trunk/gcc/tree-vrp.c:10305
0xd033f4 execute
../../gcc-trunk/gcc/tree-vrp.c:10384
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$
int a, b, c, d, f;
unsigned int e;
void
fn1 ()
{
d = b = (a != (e | 4294967288UL));
if (!d)
c = f || b;
}
[Bug libgcj/51615] Condition Variable queue state corruption and infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51615
--- Comment #3 from Igor Pashev pashev.igor at gmail dot com ---
I managed to work around this issue by disabling multithreaded compilation in
ECJ:
---
ecj-3.10.1.orig/src/org.eclipse.jdt.core/org/eclipse/jdt/internal/compiler/batch/Main.java
+++
ecj-3.10.1/src/org.eclipse.jdt.core/org/eclipse/jdt/internal/compiler/batch/Main.java
@@ -4106,7 +4106,7 @@ public void performCompilation() {
this.batchCompiler.remainingIterations =
this.maxRepetition-this.currentRepetition/*remaining iterations including this
one*/;
// temporary code to allow the compiler to revert to a single thread
String setting = System.getProperty(jdt.compiler.useSingleThread);
//$NON-NLS-1$
- this.batchCompiler.useSingleThread = setting != null
setting.equals(true); //$NON-NLS-1$
+ this.batchCompiler.useSingleThread = setting == null ||
setting.equals(true); //$NON-NLS-1$
if (this.compilerOptions.complianceLevel = ClassFileConstants.JDK1_6
this.compilerOptions.processAnnotations) {
The I recompiled eclipse-ecj.jar on a system without this issue (Debian Linux
amd64), copied this jar to my system and rebuilt ecj.
P. S. I think Debian Linux/amd64 is also affected, see Bug 51615, but
multithreaded compilation works there.
[Bug fortran/63733] [4.8/4.9/5 Regression] [OOP] wrong resolution for OPERATOR generics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63733 --- Comment #8 from janus at gcc dot gnu.org --- Author: janus Date: Sun Jan 11 22:00:06 2015 New Revision: 219440 URL: https://gcc.gnu.org/viewcvs?rev=219440root=gccview=rev Log: 2015-01-11 Janus Weil ja...@gcc.gnu.org PR fortran/63733 * interface.c (gfc_extend_expr): Look for type-bound operators before non-typebound ones. 2015-01-11 Janus Weil ja...@gcc.gnu.org PR fortran/63733 * gfortran.dg/typebound_operator_20.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/typebound_operator_20.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/interface.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 --- Comment #5 from joona.kiiski at gmail dot com --- Thanks for confirming the problem, Joost! * The original reporter stated that also 4.9 branch is affected, but I haven't tested this myself. No idea about 4.8 branch. * Latest gcc stable releases (4.7.4, 4.8.4, 4.9.2) compile Stockfish without this warning, so I assume that they are not affected. * For Stockfish, the generated code is correct (despite the wrong analysis by GCC). However I'm aware that GCC can do some aggressive optimizations in this area, so in other cases, who knows... On Sat, Jan 10, 2015 at 4:49 PM, Joost.VandeVondele at mat dot ethz.ch gcc-bugzi...@gcc.gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2015-01-04 00:00:00 |2015-1-10 CC||Joost.VandeVondele at mat dot ethz ||.ch Summary|warning: loop exit may only |[5 Regression] incorrect |be reached after undefined |warning: loop exit may only |behavior|be reached after undefined ||behavior Known to fail||5.0 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- The incorrect warning is confirmed. I wonder if this incorrect analysis could lead to wrong code generation. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug bootstrap/64561] [5 Regression] HAVE_LD_PIE_COPYRELOC is defined to 1 for broken linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64561 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||ubizjak at gmail dot com Target Milestone|--- |5.0
[Bug c++/64562] New: Member functions with r-value reference for *this and deduced return type incorrectly rejected as ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64562
Bug ID: 64562
Summary: Member functions with r-value reference for *this and
deduced return type incorrectly rejected as ambiguous
Product: gcc
Version: 4.9.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sneves at dei dot uc.pt
Consider the following program:
#include iostream
#define RETURN_TYPE auto
namespace {
struct S {
RETURN_TYPE operator--() {
return 1;
}
RETURN_TYPE operator--() const {
return 2;
}
RETURN_TYPE operator--() {
return 3;
}
RETURN_TYPE operator--() const {
return 4;
}
};
const S callme() { return {}; }
auto f1() {
return --S();
}
auto f2() {
return --callme();
}
auto f3() {
S s;
return --s;
}
auto f4() {
const S s {};
return --s;
}
}
int main() {
std::cout f1() ;
std::cout f2() ;
std::cout f3() ;
std::cout f4() std::endl;
}
The expected output would be 1 2 3 4. When RETURN_TYPE is defined to be
int, this is the result obtained. GCC (versions ranging from 4.8.2 to the
latest build), however, rejects this code when RETURN_TYPE is defined to be
auto or decltype(auto).
[Bug bootstrap/64561] New: [5 Regression] HAVE_LD_PIE_COPYRELOC is defined to 1 for broken linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64561 Bug ID: 64561 Summary: [5 Regression] HAVE_LD_PIE_COPYRELOC is defined to 1 for broken linker Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com When GCC is configured with linker without the bug fix for https://sourceware.org/bugzilla/show_bug.cgi?id=17827 it may define HAVE_LD_PIE_COPYRELOC to 1 and generate GCC which will fail to generate working executable as show in the bug report above. The fix is to incorporate the updated testcase in https://sourceware.org/ml/binutils-cvs/2015-01/msg00117.html into the linker feature check.
[Bug ipa/63470] [5 Regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 --- Comment #10 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Author: trippels Date: Mon Jan 12 07:48:50 2015 New Revision: 219445 URL: https://gcc.gnu.org/viewcvs?rev=219445root=gccview=rev Log: ipa/63470 add testcase 2015-01-11 Markus Trippelsdorf mar...@trippelsdorf.de PR ipa/63470 * ipa/pr63470.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/ipa/pr63470.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug ipa/63470] [5 Regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- Possibly fixed by (?) : https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00640.html
[Bug ipa/63470] [5 Regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 --- Comment #9 from Jan Hubicka hubicka at gcc dot gnu.org --- The ICE still reproduces for me even though at different place now. I am looking ito it.
[Bug lto/64043] [5 Regression] ICE (segfault) with LTO: in tree_check/tree.h:2758 get_binfo_at_offset/tree.c:11914
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64043 --- Comment #16 from Igor Zamyatin izamyatin at gmail dot com --- Hi, Honza! I still see that performance degradations for spec2006 tests. Could you please check those on your side?
[Bug middle-end/64491] [5 Regression] incorrect warning: loop exit may only be reached after undefined behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64491 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Known to work||4.9.2, 4.9.3 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- In my testing current 4.9 branch doesn't warn about this.
[Bug ipa/63470] [5 Regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470 --- Comment #11 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Oh, well. I will revert the addition of the testcase.
[Bug target/64368] [5 Regression] Several libstdc++ test failures on darwin and others after r218964.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64368 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #13 from Igor Zamyatin izamyatin at gmail dot com --- Hi! Any plans on fixing this?
[Bug ipa/63470] [5 Regression] internal compiler error: in estimate_edge_growth, at ipa-inline.h:308
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63470
--- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org ---
The other bug is double ajdusting of call_stmt_size when the call is turned
direct. Fixed thus:
Index: ipa-prop.c
===
--- ipa-prop.c (revision 219430)
+++ ipa-prop.c (working copy)
@@ -2736,6 +2736,7 @@
converting indirect call in %s to direct call to %s\n,
ie-caller-name (), callee-name ());
}
+ struct cgraph_edge *orig = ie;
if (!speculative)
ie = ie-make_direct (callee);
else
@@ -2750,11 +2751,16 @@
ie = ie-make_speculative
(callee, ie-count * 8 / 10, ie-frequency * 8 / 10);
}
- es = inline_edge_summary (ie);
- es-call_stmt_size -= (eni_size_weights.indirect_call_cost
-- eni_size_weights.call_cost);
- es-call_stmt_time -= (eni_time_weights.indirect_call_cost
-- eni_time_weights.call_cost);
+ /* If we resolved speuclative edge the cost is already up to date
+ for direct call (adjusted by inline_edge_duplication_hook). */
+ if (ie == orig)
+{
+ es = inline_edge_summary (ie);
+ es-call_stmt_size -= (eni_size_weights.indirect_call_cost
+- eni_size_weights.call_cost);
+ es-call_stmt_time -= (eni_time_weights.indirect_call_cost
+- eni_time_weights.call_cost);
+}
return ie;
}
Index: ipa-inline-analysis.c
===
--- ipa-inline-analysis.c (revision 219430)
+++ ipa-inline-analysis.c (working copy)
@@ -1312,6 +1312,14 @@
info-predicate = NULL;
edge_set_predicate (dst, srcinfo-predicate);
info-param = srcinfo-param.copy ();
+ if (!dst-indirect_unknown_callee src-indirect_unknown_callee)
+{
+ gcc_checking_assert (src-caller == dst-caller);
+ info-call_stmt_size -= (eni_size_weights.indirect_call_cost
+ - eni_size_weights.call_cost);
+ info-call_stmt_time -= (eni_time_weights.indirect_call_cost
+ - eni_time_weights.call_cost);
+}
}
