[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #14 from Zhenqiang Chen zhenqiang.chen at arm dot com --- Created attachment 33608 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33608action=edit patch After investigation, I found I mis-use tree_log2. Please try the attached patch. If it works, I will run all tests and send it for community review. Thanks!
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545 --- Comment #20 from rguenther at suse dot de rguenther at suse dot de --- On Fri, 26 Sep 2014, law at redhat dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545 --- Comment #14 from Jeffrey A. Law law at redhat dot com --- This feels like the kind of situation where I've always wanted a pass to be able to say something like I've done some set of transformations, schedule the appropriate cleanup passes to run. It's heavyweight, but making the tracer imply a later DOM or VRP pass might make sense. Uh that idea will lead to very big compile-time increases. One thing I'd liked to do at some point is make the SSA propagators and/or DOM work on MEME regions so we can schedule them on a sub-CFG. Richard.
[Bug tree-optimization/47413] Constant Propagation and Virtual Function Tables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
--- Comment #3 from rguenther at suse dot de rguenther at suse dot de ---
On Fri, 26 Sep 2014, hubicka at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47413
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org ---
Current mainline gets pretty close:
;; Function int f1337(obj*) (_ZL5f1337P3obj, funcdef_no=19, decl_uid=3418,
cgraph_uid=19, symbol_order=19)
int f1337(obj*) (struct obj * obj)
{
bb 2:
return 1337;
}
;; Function int main() (main, funcdef_no=22, decl_uid=3427, cgraph_uid=22,
symbol_order=22) (executed once)
Removing basic block 5
int main() ()
{
struct obj * obj;
int _1;
int _10;
bb 2:
obj_7 = malloc (8);
if (obj_7 == 0B)
goto bb 4;
else
goto bb 3;
bb 3:
obj_7-vtab = vtab1337;
_10 = f1337 (obj_7);
printf (%d\n, _10);
bb 4:
# _1 = PHI 0(2), 1(3)
return _1;
}
So we are down to one missing inline. After FRE we get:
bb 2:
obj_13 = malloc (8);
if (obj_13 == 0B)
goto bb 4;
else
goto bb 3;
bb 3:
obj_13-vtab = vtab1337;
bb 4:
# _14 = PHI 0B(2), obj_13(3)
if (_14 == 0B)
goto bb 6;
else
goto bb 5;
bb 5:
_4 = _14-vtab;
_15 = _4-f;
_16 = _15 (_14);
printf (%d\n, _16);
So purely local problem. I suppose FRE could propagate through by knowing that
on the other path program with segfault?
Not in the way value-numbering works (it value-numbers _14 as VARYING
obviously). The above feels like a missed jump-threading opportunity
to me. Eventually we could also help DOM/copyprop with replacing
the test by _14 != ohj_13 ...
In my view DOM should be able to figure out a value for _14
on the else edge as well (doesn't exactly fit DOM but certainly
most easily implemented there)
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2014-09-29 CC||jiwang at gcc dot gnu.org, ||trippels at gcc dot gnu.org Ever confirmed|0 |1 Summary|gcc 5 miscompiles linux |[5 Regression] gcc 5 |block layer |miscompiles linux block ||layer Target Milestone|--- |5.0 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r215563.
[Bug fortran/37173] Check whether intrinsic assignment between character kind=1 / 4 is allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173 --- Comment #5 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Tobias Burnus from comment #3) We still might add a -std=f2008 check there. I find the same wording in my local copy of F2003, actually: If variable and expr have different kind type parameters, each character c in expr is converted to the kind type parameter of variable by ACHAR(IACHAR(c),KIND(variable)). (ISO/IEC JTC1/SC22/WG5 N1578 dated 2003-10-8) (In reply to Dominique d'Humieres from comment #4) (5) if the variable is of type character and of ISO 10646, ASCII, or default character kind, expr shall be of ISO 10646, ASCII, or default character kind, (6) otherwise if the variable is of type character expr shall have the same kind type parameter, I think there is a reasonable interpretation where it does not conflict: it means ISO 10646 and ASCII and default interconvert, but not necessarily other character kinds. It does not say, for example, expr shall be of ISO 10646, ASCII, or default character kind (*respectively*).
[Bug fortran/37173] Check whether intrinsic assignment between character kind=1 / 4 is allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #6 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- So, given the clear change in wording since the 2008 interp, I close this report as INVALID.
[Bug fortran/36534] Bogus: '__convert_s1_s4' at (1) is obsolescent in fortran 95
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36534 Bug 36534 depends on bug 37173, which changed state. Bug 37173 Summary: Check whether intrinsic assignment between character kind=1 / 4 is allowed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37173 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID
[Bug libstdc++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Piotr Dziwinski from comment #1) I would also second the proposal to fix this issue by implementing flat version of std::tuple. Perhaps the existing std::tr1::tuple implementation can be re-used here? GCC's std::tr1:tuple is not a flat implementation, and does not conform to the C++11 requirements, so no, that's not an option.
[Bug c++/51385] Unnecessary instantiation converting to pointer to template class instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.0, I'm adding the testcase and closing the bug.
[Bug c++/63405] New: Internal compiler error when building OpenAxiom on linux/amd64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Bug ID: 63405
Summary: Internal compiler error when building OpenAxiom on
linux/amd64
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pashev.igor at gmail dot com
Created attachment 33609
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33609action=edit
Preprocessed file
Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761549
Error message:
make[3]: Entering directory
'/home/pashev/work/projects/pkg-open-axiom/build-tree/src/syntax'
g++ -DHAVE_CONFIG_H -I. -I../../../src/syntax -I../../config
-I../../../src/include -I../../x86_64-pc-linux-gnu/include -D_FORTIFY_SOURCE=2
-m64 -D_GNU_SOURCE -std=c++11 -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -O2 -Wall -c -o libsyntax_a-sexpr.o `test -f 'sexpr.cc'
|| echo '../../../src/syntax/'`sexpr.cc
In file included from ../../x86_64-pc-linux-gnu/include/open-axiom/sexpr:47:0,
from ../../../src/syntax/sexpr.cc:39:
../../x86_64-pc-linux-gnu/include/open-axiom/storage: In instantiation of 'T*
OpenAxiom::Memory::FactoryT::make(const Args ...) [with Args =
{std::vectorconst OpenAxiom::Sexpr::Syntax*, std::allocatorconst
OpenAxiom::Sexpr::Syntax* , bool}; T = OpenAxiom::Sexpr::ListSyntax]':
../../../src/syntax/sexpr.cc:345:37: required from here
../../x86_64-pc-linux-gnu/include/open-axiom/storage:273:52: internal compiler
error: in cp_perform_integral_promotions, at cp/typeck.c:2066
return new(this-allocate(1)) T{args...};
^
# g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++-4.9.real
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.1-14'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-14)
[Bug c++/51385] Unnecessary instantiation converting to pointer to template class instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 29 09:06:31 2014 New Revision: 215680 URL: https://gcc.gnu.org/viewcvs?rev=215680root=gccview=rev Log: 2014-09-29 Paolo Carlini paolo.carl...@oracle.com PR c++/51385 * g++.dg/template/pr51385.C: New. Added: trunk/gcc/testsuite/g++.dg/template/pr51385.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/51385] Unnecessary instantiation converting to pointer to template class instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51385 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
--- Comment #1 from Igor Zamyatin izamyatin at gmail dot com ---
Would like to ask here first - will something like following be ok:
diff --git a/gcc/c-family/cilk.c b/gcc/c-family/cilk.c
index bf549ad..f453bc5 100644
--- a/gcc/c-family/cilk.c
+++ b/gcc/c-family/cilk.c
@@ -36,6 +36,7 @@ along with GCC; see the file COPYING3. If not see
#include toplev.h
#include cgraph.h
#include diagnostic.h
+#include vec.h
#include cilk.h
enum add_variable_type {
@@ -332,15 +333,23 @@ create_cilk_helper_decl (struct wrapper_data *wd)
return fndecl;
}
+typedef struct
+{
+ tree parm;
+ tree arg;
+} decl_pair;
+
+static vecdecl_pair vec_arglist;
+
/* A function used by walk tree to find wrapper parms. */
static bool
wrapper_parm_cb (const void *key0, void **val0, void *data)
{
- struct wrapper_data *wd = (struct wrapper_data *) data;
tree arg = * (tree *)key0;
tree val = (tree)*val0;
tree parm;
+ decl_pair dp;
if (val == error_mark_node || val == arg)
return true;
@@ -370,25 +379,48 @@ wrapper_parm_cb (const void *key0, void **val0, void
*data)
}
else
parm = val;
- TREE_CHAIN (parm) = wd-parms;
- wd-parms = parm;
- wd-argtypes = tree_cons (NULL_TREE, TREE_TYPE (parm), wd-argtypes);
- wd-arglist = tree_cons (NULL_TREE, arg, wd-arglist);
+
+ dp.parm = parm;
+ dp.arg = arg;
+ vec_arglist.safe_push(dp);
return true;
}
/* This function is used to build a wrapper of a certain type. */
+static int
+compare_decls (const void *a, const void *b)
+{
+const decl_pair* t1 = (const decl_pair*) a;
+const decl_pair* t2 = (const decl_pair*) b;
+
+return DECL_UID(t1-arg) DECL_UID(t2-arg);
+}
+
static void
build_wrapper_type (struct wrapper_data *wd)
{
+ unsigned int j;
+ decl_pair * c;
wd-arglist = NULL_TREE;
wd-parms = NULL_TREE;
wd-argtypes = void_list_node;
- pointer_map_traverse (wd-decl_map, wrapper_parm_cb, wd);
+ vec_arglist.create (0);
+ pointer_map_traverse (wd-decl_map, wrapper_parm_cb, NULL);
gcc_assert (wd-type != CILK_BLOCK_FOR);
+ vec_arglist.qsort(compare_decls);
+
+ FOR_EACH_VEC_ELT (vec_arglist, j, c)
+{
+ TREE_CHAIN (c-parm) = wd-parms;
+ wd-parms = c-parm;
+ wd-argtypes = tree_cons (NULL_TREE, TREE_TYPE (c-parm), wd-argtypes);
+ wd-arglist = tree_cons (NULL_TREE, c-arg, wd-arglist);
+}
+ vec_arglist.release();
+
/* Now build a function.
Its return type is void (all side effects are via explicit parameters).
Its parameters are WRAPPER_PARMS with type WRAPPER_TYPES.
Bootstrapped successfully with GCC_COMPARE_DEBUG=1
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target||mingw-w64 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Which of macros are defined on mingw-w64? Preprocessing this should tell you #include chrono #ifdef _GLIBCXX_USE_CLOCK_REALTIME #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL #warning system_clock using syscall(SYS_clock_gettime, CLOCK_REALTIME, tp); #else #warning system_clock using clock_gettime(CLOCK_REALTIME, tp); #endif #elif defined(_GLIBCXX_USE_GETTIMEOFDAY) #warning system_clock using gettimeofday(tv, 0); #else #warning system_clock using std::time(0); #endif #ifdef _GLIBCXX_USE_CLOCK_MONOTONIC #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL #warning steady_clock using syscall(SYS_clock_gettime, CLOCK_MONOTONIC, tp); #else #warning steady_clock using clock_gettime(CLOCK_MONOTONIC, tp); #endif #else #warning steady_clock using time_point(system_clock::now().time_since_epoch()); #endif
[Bug c/63307] [4.9/5 Regression] Cilk+ breaks -fcompare-debug bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63307
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Igor Zamyatin from comment #1)
Would like to ask here first - will something like following be ok:
+typedef struct
+{
+ tree parm;
+ tree arg;
+} decl_pair;
+
+static vecdecl_pair vec_arglist;
Just use struct cilk_decl_pair, no need for typedef in C++ here, and
try to avoid ODR issues. Also, why a static variable? Then you supposedly
would need to GTY handle it etc., which is IMHO undesirable.
static bool
wrapper_parm_cb (const void *key0, void **val0, void *data)
{
- struct wrapper_data *wd = (struct wrapper_data *) data;
tree arg = * (tree *)key0;
tree val = (tree)*val0;
tree parm;
+ decl_pair dp;
if (val == error_mark_node || val == arg)
return true;
@@ -370,25 +379,48 @@ wrapper_parm_cb (const void *key0, void **val0, void
*data)
}
else
parm = val;
- TREE_CHAIN (parm) = wd-parms;
- wd-parms = parm;
- wd-argtypes = tree_cons (NULL_TREE, TREE_TYPE (parm), wd-argtypes);
- wd-arglist = tree_cons (NULL_TREE, arg, wd-arglist);
+
+ dp.parm = parm;
+ dp.arg = arg;
+ vec_arglist.safe_push(dp);
Formatting, missing space before (. But more importantly, the diagnostics
still be in random order. So, I'd strongly suggest to move also the
diagnostics and ADDR_EXPR building etc. into a loop that walks the sorted
vector.
return true;
}
/* This function is used to build a wrapper of a certain type. */
+static int
+compare_decls (const void *a, const void *b)
+{
+const decl_pair* t1 = (const decl_pair*) a;
+const decl_pair* t2 = (const decl_pair*) b;
+
+return DECL_UID(t1-arg) DECL_UID(t2-arg);
Formatting. Space before *, not after, space before (, indentation 2 columns
rather than 4.
+}
+
static void
build_wrapper_type (struct wrapper_data *wd)
{
+ unsigned int j;
+ decl_pair * c;
wd-arglist = NULL_TREE;
wd-parms = NULL_TREE;
wd-argtypes = void_list_node;
- pointer_map_traverse (wd-decl_map, wrapper_parm_cb, wd);
+ vec_arglist.create (0);
+ pointer_map_traverse (wd-decl_map, wrapper_parm_cb, NULL);
gcc_assert (wd-type != CILK_BLOCK_FOR);
+ vec_arglist.qsort(compare_decls);
Formatting.
+
+ FOR_EACH_VEC_ELT (vec_arglist, j, c)
+{
+ TREE_CHAIN (c-parm) = wd-parms;
+ wd-parms = c-parm;
+ wd-argtypes = tree_cons (NULL_TREE, TREE_TYPE (c-parm),
wd-argtypes);
+ wd-arglist = tree_cons (NULL_TREE, c-arg, wd-arglist);
+}
As I said earlier, I'd do diagnostics and ADDR_EXPR creation in this loop too.
+ vec_arglist.release();
Formatting. You could use auto_vec, perhaps with some stack allocated initial
buffer if you think say 16 vector elements would be typically enough.
Also, what about all the remaining 3 callbacks that create or may create decls
and have the same problem? for_local_cb, wrapper_local_cb and
declare_one_free_variable.
[Bug tree-optimization/63406] New: -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406
Bug ID: 63406
Summary: -Warray-bounds false positive with -O3
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
int total_objs = 0;
#ifndef N
#define N 2
#endif
void *objs[N];
void
del_obj (void *obj)
{
int i = 0;
while (i total_objs objs[i] != obj)
++i;
if (i = total_objs)
return;
while (++i total_objs)
objs[i - 1] = objs[i];
--total_objs;
}
Both loops seem to be unrolled N times (although the second loop clearly could
be
only executed N-1 times, because otherwise it triggers undefined behavior in
the loop), and after unrolling the misdesigned -Warray-bounds warning complains
on the last iteration of the unrolled loop.
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 Julian Taylor jtaylor.debian at googlemail dot com changed: What|Removed |Added CC||jtaylor.debian at googlemail dot c ||om --- Comment #21 from Julian Taylor jtaylor.debian at googlemail dot com --- this fix causes another ICE, see PR63342 but it doesn't seem to affect the current 4.9 and 4.8 branches, so there is probably some other interaction with a 5.0 change causing it.
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #21 from rguenther at suse dot de rguenther at suse dot de ---
nOn Sat, 27 Sep 2014, hubicka at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
Jan Hubicka hubicka at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||mliska at suse dot cz
Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot
gnu.org
--- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org ---
I have moved tracer before the late cleanups that seems to be rather obbious
thing to do. This lets us to optimize the testcase (with -O2):
int main() ()
{
struct A * ap;
int i;
int _6;
bb 2:
bb 3:
# i_29 = PHI i_22(6), 0(2)
_6 = i_29 % 7;
if (_6 == 0)
goto bb 4;
else
goto bb 5;
bb 4:
ap_8 = operator new (16);
ap_8-i = 0;
ap_8-_vptr.A = MEM[(void *)_ZTV1A + 16B];
goto bb 6;
bb 5:
ap_13 = operator new (16);
MEM[(struct B *)ap_13].D.2244.i = 0;
MEM[(struct B *)ap_13].b = 0;
MEM[(struct B *)ap_13].D.2244._vptr.A = MEM[(void *)_ZTV1B + 16B];
bb 6:
# ap_4 = PHI ap_13(5), ap_8(4)
operator delete (ap_4);
i_22 = i_29 + 1;
if (i_22 != 1)
goto bb 3;
else
goto bb 7;
bb 7:
return 0;
}
Martin, I do not have SPEC setup, do you think you can benchmark the attached
patch with SPEC and profile feedback and also non-FDO -O3 -ftracer compared to
-O3, please?
It would be nice to know code size impact, too.
Index: passes.def
===
--- passes.def (revision 215651)
+++ passes.def (working copy)
@@ -155,6 +155,7 @@ along with GCC; see the file COPYING3.
NEXT_PASS (pass_dce);
NEXT_PASS (pass_call_cdce);
NEXT_PASS (pass_cselim);
+ NEXT_PASS (pass_tracer);
NEXT_PASS (pass_copy_prop);
NEXT_PASS (pass_tree_ifcombine);
NEXT_PASS (pass_phiopt);
@@ -252,7 +253,6 @@ along with GCC; see the file COPYING3.
NEXT_PASS (pass_cse_reciprocals);
NEXT_PASS (pass_reassoc);
NEXT_PASS (pass_strength_reduction);
- NEXT_PASS (pass_tracer);
NEXT_PASS (pass_dominator);
NEXT_PASS (pass_strlen);
NEXT_PASS (pass_vrp);
Doing it at same approximately the same place as loop header copying seems to
make most sense to me. It benefits from early cleanups and DCE definitly and
it should enable more fun with the later scalar passes that are almost all
rerun then.
We need to make sure tracer doesn't mess too much with loops then.
Btw, useless tracing may be undone again by tail-merging.
Tracer seems to consume only profile information and thus doesn't
rely on any other transforms (well, apart from cleanups which could
affect its cost function). Why not schedule it even earlier?
Like to before pass_build_alias? (the pipeline up to loop transforms
is quite a mess...)
[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- We could also make $0 a not legitimate constant on x86... (and undo that late with a peephole2)
[Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605 vries at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-29 CC||vries at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from vries at gcc dot gnu.org --- If a function is known to not clobber an argument register then the caller shouldn't have to save/reload that register across the function call. If a function is known to not clobber an call_used_reg then the caller can use it as a non-call_used_reg across the function call. This diff shows the example with -fno-use-caller-save vs -fuse-caller-save: ... foo: .LFB1: .cfi_startproc -pushq%rbx -.cfi_def_cfa_offset 16 -.cfi_offset 3, -16 -movl%edi, %ebx +movl%edi, %edx callbar -addl%ebx, %eax -popq%rbx -.cfi_def_cfa_offset 8 +addl%edx, %eax ret .cfi_endproc .LFE1: ... -fuse-caller-save removes the entry/exit save/restore pair 'pushq %rbx'/'popq %rbx'. The 'movl %edi, %edx' is indeed non-optimal, but it's not a 'save' in the sense of save/restore pair generated at function entry/exit or around function calls. It's a copy at function entry of a hard reg argumument to a pseudo reg, generated at expand, which is followed by a copy of the pseudo reg to the same register to set the argument for the function call: ... (insn 2 4 3 2 (set (reg/v:SI 86 [ yD.1755 ]) (reg:SI 5 di [ yD.1755 ])) test.c:9 -1 (nil)) (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG) (insn 6 3 7 2 (set (reg:SI 5 di) (reg/v:SI 86 [ yD.1755 ])) test.c:10 -1 (nil)) ... The second insn is removed in pass_fast_rtl_dce. The reg-alloc choiche for pseudo 86 in the first insn is dx, and the insn remains. I think there could be two ways to address this: 1. Teach a pass after ira, like pass_cprop_hardreg or pass_gcse2 to use the information collected by fuse-calller-save. 2. Teach ira to prefer the dx to di in this case. My guess would be pass_cprop_hardreg.
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602
--- Comment #10 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Andi Kleen from comment #9)
Any progress on fixing the test case, so that this can be finally fixed?
I have no idea how to do that without making the testcase test sth different.
We could of course simply turn off SRA for it ...
That said, the difference the optimization may cause might be surprising to
people. That is, that the following may abort()
struct f { char c; int i; };
struct f2 { int i; int j; };
int main()
{
struct f f;
struct f2 f2;
memset(f, 0, sizeof (f));
memcpy(f2, f, sizeof (f));
if (memcmp (f, f2) != 0)
abort ();
return 0;
}
because suddenly the semantics of a memset and a memcpy depend on the
type (_what_ type?!) of the pointed-to type.
Note we can simply circumvent the issue by using a char[n] typed
CONSTRUCTOR / type for the copy. Sth I wanted to followup with
now that the folding happens always on GIMPLE.
It seems to me that SRA may not simply omit padding for aggregate
copies if it cannot prove that the padding is not used. At least
on GIMPLE the semantics of an aggregate assignment is that of a
memmove, not of a field-wise copy. Martin - can you look into this
wrong-code bug? Basically if SRA decides it needs to re-materialize
the object (here before the memcmp call) then it has to re-materialize
padding as well.
[Bug middle-end/63383] internal compiler error: in expand_expr_real_1, at expr.c:9389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63383 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-29 Component|c++ |middle-end Version|unknown |4.8.3 Ever confirmed|0 |1 Known to fail||4.8.3, 4.9.2, 5.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #4 from Jiong Wang jiwang at gcc dot gnu.org --- sorry for causing the trouble. the reason might be the flag is an implified register while it's not take into account in current shrink-wrap reg read/write analysis. I will revert my patch temperarily if I couldn't find a proper fix today.
[Bug c++/63386] Release version of CB wont compile Bullet (-o2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63386 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Please provide preprocessed source of the file crashing the compiler.
[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-29 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed. I hope to get the branch merged (partially) soon.
[Bug other/63395] Cygwin vs Cygwin64 Floating Point Discrepancy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org --- You can also try -fexcess-precision=standard on Cygwin, -mpc64 might not be implemented there.
[Bug ipa/63403] [5.0 Regression] ICE: in relative_time_benefit at ipa-inline.c:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |5.0
[Bug tree-optimization/63406] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I think we have similar dups elsewhere (warning for last unrolled iteration which is never executed). My previous naiive attempts dropped warnings from VRP2 and only warn from VRP1 (but that regresses some cases in the testsuite).
[Bug tree-optimization/63406] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63406 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- I'd say it would still be worthwhile, if it was just a matter of XFAILing a few testcases, because the number of false positives is more important, if the warning is too unreliable, people just will ignore it completely. And people can combine it with -fsanitize=undefined, Fortran -fbounds-check etc.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #5 from Jiong Wang jiwang at gcc dot gnu.org --- we need to check the following else if (GET_CODE == CLOBBER || GET_CODE (x) == USE || GET_CODE (x) == ASM_INPUT) I will post the fix after pass x86 bootstrap and regression
[Bug ada/34117] enable overflow checks by default (-gnato)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34117 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org --- overflow checks will be enabled by default in the 5.x series.
[Bug c++/63405] [5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-29
CC||trippels at gcc dot gnu.org
Known to work||4.8.3, 4.9.2
Version|4.9.1 |5.0
Target Milestone|--- |5.0
Summary|Internal compiler error |[5 regression] ICE in
|when building OpenAxiom on |cp_perform_integral_promoti
|linux/amd64 |ons, at cp/typeck.c:2084
Ever confirmed|0 |1
Known to fail||5.0
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
I can only reproduce this on trunk. 4.9 branch is fine.
markus@x4 tmp % cat sex.ii
struct ListSyntax {
ListSyntax(int, bool);
};
struct A {
template typename... Args
ListSyntax *m_fn1(Args ... args) {
return new ListSyntax{args...};
}
};
struct B {
const ListSyntax *m_fn2(const int , bool);
A lists;
};
const ListSyntax *B::m_fn2(const int elts, bool dot) {
return lists.m_fn1(elts, dot);
}
markus@x4 tmp % /var/tmp/gcc_test/usr/local/bin/g++ -std=c++11 -c sex.ii
sex.ii: In instantiation of ‘ListSyntax* A::m_fn1(Args ...) [with Args =
{const int, bool}]’:
sex.ii:15:31: required from here
sex.ii:7:34: internal compiler error: in cp_perform_integral_promotions, at
cp/typeck.c:2084
return new ListSyntax{args...};
^
0x6b79d1 cp_perform_integral_promotions(tree_node*, int)
../../gcc/gcc/cp/typeck.c:2084
0x57335a convert_for_arg_passing(tree_node*, tree_node*, int)
../../gcc/gcc/cp/call.c:6799
0x577b83 build_over_call
../../gcc/gcc/cp/call.c:7211
0x5835f5 build_new_method_call_1
../../gcc/gcc/cp/call.c:8098
0x5835f5 build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8168
0x584569 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/gcc/cp/call.c:7712
0x6e564b build_new_1
../../gcc/gcc/cp/init.c:2846
0x6e5d16 build_new(vectree_node*, va_gc, vl_embed**, tree_node*, tree_node*,
vectree_node*, va_gc, vl_embed**, int, int)
../../gcc/gcc/cp/init.c:3086
0x5fc209 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:14848
0x5db056 tsubst_expr
../../gcc/gcc/cp/pt.c:14272
0x5dc89c tsubst_expr
../../gcc/gcc/cp/pt.c:13679
0x5dbe60 tsubst_expr
../../gcc/gcc/cp/pt.c:13855
0x5d90fd instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:20227
0x61f727 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:20343
0x65c9e4 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4367
Please submit a full bug report,
[Bug rtl-optimization/61605] Potential optimization: Keep unclobbered argument registers live across function calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61605
--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 33610
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33610action=edit
proof-of-concept patch
Using this proof-of-concept patch, we manage to get the desired code. The patch
uses the fuse-caller-save information in cprop-hardreg, and runs cprop-hardreg
one more time, after pass_fast_rtl_dce.
Obviously it's not desirable to run cprop-hardreg twice. But the pass has
problems with this code:
...
(insn 2 18 3 2 (set (reg/v:SI 1 dx [orig:86 yD.1749 ] [86])
(reg:SI 5 di [ yD.1749 ])) test.c:9 90 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 5 di [ yD.1749 ])
(nil)))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:SI 5 di)
(reg/v:SI 1 dx [orig:86 yD.1749 ] [86])) test.c:10 90 {*movsi_internal}
(nil))
...
The first time cprop-hardreg runs, it manages to propagate the first copy (insn
2) to the second (insn 6):
...
rescanning insn with uid = 6.
insn 6: replaced reg 1 with 5
...
So insn 6 looks like:
...
(insn 6 3 7 2 (set (reg:SI 5 di)
(reg:SI 5 di [orig:86 yD.1749 ] [86])) test.c:10 90 {*movsi_internal}
(nil))
...
That insn is remove by pass_fast_rtl_dce:
...
DCE: Deleting insn 6
deleting insn with uid = 6.
...
And only the second time we run it, we propagate the first copy to the add:
...
insn 9: replaced reg 1 with 5
rescanning insn with uid = 9.
...
which then looks like this:
...
(insn 9 7 15 2 (parallel [
(set (reg:SI 0 ax [orig:87 D.1767 ] [87])
(plus:SI (reg:SI 0 ax [orig:83 D.1767 ] [83])
(reg:SI 5 di [orig:86 yD.1749 ] [86])))
(clobber (reg:CC 17 flags))
]) test.c:10 220 {*addsi_1}
(expr_list:REG_DEAD (reg/v:SI 1 dx [orig:86 yD.1749 ] [86])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
...
That leaves insn 2 dead, which is deleted by dce during sched2:
...
DCE: Deleting insn 2
deleting insn with uid = 2.
...
I'm not sure yet why the cprop-hardreg doesn't work for both cases the first
time, but it's probably that the store to di by insn 6 is registered as a kill
by cprop-hardreg, not taking into account that it's the same value.
[Bug c++/63262] internal compiler error including math.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63262 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #1 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Could you come up with a preprocessed source file showing the bug? Rerun your command (/usr/local/bin/g++ -o gmic gmic.cpp ...) adding the -save-temps option. This should generate a gmic.ii file, which you can attach here. It will allow us to reproduce the issue without having to download and set up the full gmic source code.
[Bug tree-optimization/63302] [4.9 Regression] Code with 64-bit long long constants is miscompiled on 32-bit host
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63302 --- Comment #15 from dave.anglin at bell dot net --- On 29-Sep-14, at 2:43 AM, zhenqiang.chen at arm dot com wrote: Please try the attached patch. If it works, I will run all tests and send it for community review. The patch appears to fix the testcase. I've started a full build and check with 4.9 branch. I'll also test it on hpux starting this evening. Thanks very much for investigating. Dave -- John David Anglindave.ang...@bell.net
[Bug c++/19808] miss a warning about uninitialized members in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #22 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #21)
I just got hit by this bug. This can obviously be warned in the FE as clang
does:
test.cc:4:11: warning: field 'j' is uninitialized when used here
[-Wuninitialized]
S() : i(j), j(1) {}
^
simply by marking the members somehow as initialized or not, and when using
them realizing that they are still uninitialized.
Marek, Paolo, Jason? Any idea how to do this?
It could be done specifically for uses in mem-initializers by walking the
initializer in perform_mem_init to look for any references to members that
haven't been marked yet.
A more general warning that would cover, say,
X x;
x.x = x.y;
would need support in the existing back end -Wuninitialized code.
[Bug c++/62164] 5.0: ICE: error: Both section and comdat group is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62164 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #2) The sections for COMDAT functions are used to drive code unification. I wonder, do we want to support something like this (and expect that user knows what he is doing and he won't, for example, drop multiple COMDATs into one section) or just reject the attribute? What's wrong with dropping multiple COMDATs into one section? Don't we normally stick lots of COMDATs into .text?
[Bug other/63407] New: xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 Bug ID: 63407 Summary: xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: nheghathivhistha at gmail dot com Gentoo dev-cpp/xsd-3.3.0-r3 compiled (without troubles) with -flto=4 -fuse-linker-plugin aborts itself during processing of net-libs/libkolabxml-1.0.1 xsd files with message: terminate called after throwing an instance of 'Cult::MM::Absent'. When LTO is not used to compile xsdcxx program problem is not present. -rwxr-xr-x 1 root root 3911616 Sep 29 15:00 /usr/bin/xsdcxx -rwxr-xr-x 1 root root 4527928 Sep 29 14:15 /usr/bin/xsdcxx.nolto gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140928/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140928/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.9.2_alpha20140928/work/gcc-4.9-20140928/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.2-alpha20140928 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140928/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140928 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140928/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140928/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.2-alpha20140928/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.2-alpha20140928/python --enable-languages=c,c++,go,objc,obj-c++,fortran,ada --enable-obsolete --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.2_alpha20140928' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --enable-lto --with-cloog --disable-isl-version-check Thread model: posix gcc version 4.9.2-alpha20140928 20140929 (prerelease) [gcc-4_9-branch revision 215679] (Gentoo 4.9.2_alpha20140928) C(XX)FLAGS -flto=4 -fuse-linker-plugin -O2 -g -pipe -march=core2 -mtune=core2 I am going to try version 5 from svn. Should I post disassemble diff output or how to continue please? I not enabled static libraries on my system so upload of binaries itself will be problem.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #11 from boger at us dot ibm.com --- On ppc64 BE, the call to make_code_func_reference returns the function pointer in the .opd and not the actual address of the function. That is what causes the failures with this patch https://gcc.gnu.org/ml/gcc-patches/2014-09/msg00710.html The information in this reply fixes the regressions from this patch on ppc64 BE: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02282.html Essentially the change is to dereference the function pointer in __go_set_defering_fn when building for ppc64 BE as follows: +#if defined(__powerpc64__) _CALL_ELF != 2 +g-defer-__defering_fn = *(void **)defering_fn; +#else +g-defer-__defering_fn = defering_fn; +#endif
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #1 from David Kredba nheghathivhistha at gmail dot com --- gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.10.0-alpha20140928/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.10.0-alpha20140928/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.10.0_alpha20140928/work/gcc-4.10-20140928/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.10.0-alpha20140928 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-alpha20140928/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-alpha20140928 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-alpha20140928/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-alpha20140928/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.10.0-alpha20140928/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.10.0-alpha20140928/python --enable-languages=c,c++,fortran,ada --enable-obsolete --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.10.0_alpha20140928' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --enable-lto --with-cloog --disable-isl-version-check Thread model: posix gcc version 4.10.0-alpha20140928 20140929 (experimental) [trunk revision 215679] (Gentoo 4.10.0_alpha20140928) fails the same way: terminate called after throwing an instance of 'Cult::MM::Absent' what(): N4Cult2MM6AbsentE /bin/sh: řádek 1: 16792 Neúspěšně ukončen (SIGABRT)/usr/bin/xsdcxx cxx-tree --generate-polymorphic --generate-serialization --namespace-map http://kolab.org=KolabXSD --root-element icalendar --root-element vcards --root-element note --root-element configuration --root-element file --output-dir /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1_build/bindings /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/ical/kolabformat-xcal.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/ical/iCalendar-params.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/ical/iCalendar-props.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/ical/iCalendar-valtypes.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/kolabformat-xcard.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/xCard.xsd /var/tmp/portage/net-libs/libkolabxml-1.0.1/work/libkolabxml-1.0.1/schemas/kolabformat.xsd
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #2 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 33611 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33611action=edit xsd files with folder structure
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #3 from David Kredba nheghathivhistha at gmail dot com --- objdump -d produced 24 and 30 MiB files and diff -u is 50 MiB, diff 55 MiB. Even 7z can compress it to uploadable size.
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #3 from Piotr Dziwinski piotrdz at gmail dot com --- (In reply to Jonathan Wakely from comment #2) (In reply to Piotr Dziwinski from comment #1) I would also second the proposal to fix this issue by implementing flat version of std::tuple. Perhaps the existing std::tr1::tuple implementation can be re-used here? GCC's std::tr1:tuple is not a flat implementation, and does not conform to the C++11 requirements, so no, that's not an option. Oh, you're right - somehow I got convinced that std::tr1::tuple was a flat implementation since it compiles so much faster. But this raises a question - why do the two recursive implementations have such different compile times? Perhaps by analyzing the differences between std::tr1::tuple and std::tuple, we can learn something to our advantage?
[Bug c++/19808] miss a warning about uninitialized members in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808 --- Comment #23 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jason Merrill from comment #22) It could be done specifically for uses in mem-initializers by walking the initializer in perform_mem_init to look for any references to members that haven't been marked yet. Great! If I find some time in the following weeks, I will give it a try. A more general warning that would cover, say, X x; x.x = x.y; would need support in the existing back end -Wuninitialized code. That is PR2972 and I think fixing this one is a prerequisite for fixing that one. So let's go step by step.
[Bug c++/62056] Long compile times with large tuples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62056 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- tr1::tuple doesn't support perfect-forwarding or move semantics tr1::tuple doesn't support uses-allocator construction tr1::tuple doesn't support 'final' classes tr1::tuple doesn't have correct exception specifications tr1::tuple doesn't prevent implicit conversions that would use explicit constructors tr1::tuple doesn't support tuple concatenation If you can add all those features to the tr1/tuple implementation so that it meets the C++11 requirements and it still compiles faster then I'd be interested in your analysis of the remaining differences. Otherwise I'm going to assume the difference is because the tuple header contains more than twice as many lines of code and several additional features.
[Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #20) Perhaps a better alternative is to warn only if the uninitialized member is used in a mem-initializer. Then, when building the constructor call, mark the uninitialized members somehow as uninitialized for the middle-end, and let the middle-end handle the cases in the body of the constructor. The first part would already fix PR19808. The second part will fix this bug with fewer false positives than the proposed patch. And this comment gives some ideas: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19808#c9 Richard B, you say that: using error-mark [for marking undefined memory] is just a random (and probably bad) idea. Intuitively this seems more scalable, since one could propagate the undefined value like VRP does. The other alternative Introducing a SSA name default definition for A (even though not of register type), however, seems possible already. no? We do already check for default definitions in virtual operands, tree-ssa-uninit.c says: /* For memory the only cheap thing we can do is see if we have a use of the default def of the virtual operand. So what is missing here?
[Bug target/63408] New: GCC emits incorrect FMA instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
Bug ID: 63408
Summary: GCC emits incorrect FMA instruction
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: itay at phobotic dot com
When compiling the following function
float f(float a, int b)
{
return a - (((float)b / 0x7fff) * 100);
}
with the following command-line options
arm-none-eabi-gcc -O2 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=softfp
-mcpu=cortex-m4
I get this code for f:
fmsrs14, r1@ int
fldss15, .L2
vcvt.f32.s32s14, s14, #31
fmsrs13, r0
vfma.f32s13, s14, s15
fmrsr0, s13
bxlr
.L3:
.align2
.L2:
.word1120403456
The resulting code clearly adds the parenthesized expression to a rather than
subtracting it.
Replacing the minus sign with a plus sign results in the same code.
[Bug debug/63342] [5 Regression] ICE in loc_list_from_tree, at dwarf2out.c:14698
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63342 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 33612 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33612action=edit gcc5-pr63342.patch Untested fix. When because of r214899 mem_loc_descriptor (correctly) gives up (previously we were generating wrong debug info), we retry by trying to generate debug info from the MEM_EXPR of the MEM, but in this case it contains a TARGET_MEM_REF which we weren't handling at all. Perhaps we should just return NULL for TARGET_MEM_REF though, because we can't do anything for SSA_NAMEs anyway, and I doubt there could be a TARGET_MEM_REF in MEM_EXPR which would not mention SSA_NAMEs. The ultimate reason for not generating debug info is that the TLSLD model base address is precomputed into some register (as it is used multiple times in the function) and ix86_delegitimize_tls_address can't know which hard register holds the base address, so the delegitimization fails. In theory we probably could emit the symbol@DTPOFF into assembly, but as we right now reject all UNSPECs that weren't successfully delegitimized, we reject it anyway.
[Bug rtl-optimization/63340] [5.0 regression] FAIL: gcc.dg/atomic/c11-atomic-exec-2.c -O2 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63340 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-09-29 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Sorry for the slow response to this. Been looking for a way out that looks reasonable, think I finally have one. The problem is to do with the union class GR_AND_FR_REGS. Before my patch this was rejected if a register underwant a mode change that is forbidden by FR_REGS, whereas after the patch it is accepted. Testing a patch now, but I expect it will need a couple of revisions.
[Bug debug/63285] [4.9 Regression] -fcompare-debug scheduler related failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63285
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Vlad, do you plan to apply this to 4.9 and 4.8 branches too?
For 4.9, I've bootstrapped/regtested it on {x86_64,i686,armv7hl,aarch64}-linux.
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #4 from David Kredba nheghathivhistha at gmail dot com --- Created attachment 33613 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33613action=edit all ii files compressed by 7zip tar.bz2 file size was 8.2 MiB.
[Bug other/63407] xsdcxx built with LTO aborts on xsd files of libkolabxml - when LTO is disabled problem is gone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63407 --- Comment #5 from David Kredba nheghathivhistha at gmail dot com --- Link command to produce a binary, Boost is 1.56: x86_64-pc-linux-gnu-g++ -flto=4 -fuse-linker-plugin -O2 -g -save-temps -march=core2 -mtune=core2 -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2 -Wl,-flto -fuse-linker-plugin -Wl,--as-needed -Wl,-O2 -Wl,--sort-common -Wl,--hash-style=gnu -O2 -g -pipe -march=core2 -mtune=core2 -o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/xsd /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/xsd.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/literal-map.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/validator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/name-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/type-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/state-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/generator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-inline.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/parser-forward.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/impl-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/impl-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/driver-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/element-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/attribute-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/parser/characters-validation-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/elements.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/validator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/counter.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/name-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/polymorphism-processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/default-value.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/generator.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/tree-forward.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/tree-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/tree-inline.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/tree-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/parser-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/parser-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/serialization-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/serialization-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-insertion-header.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-insertion-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/cxx/tree/stream-extraction-source.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/type-map/lexer.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/type-map/parser.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/processing/cardinality/processor.o /var/tmp/portage/dev-cpp/xsd-3.3.0-r3/work/xsd-3.3.0/xsd/processing/inheritance/processor.o /usr/lib/libxsd-frontend.so /usr/lib/libfrontend-elements.so /usr/lib/libcult.so /usr/lib/libboost_filesystem.so /usr/lib/libxerces-c.so /usr/lib/libboost_regex.so /usr/lib/libboost_system.so
[Bug lto/62061] [5 Regression] FAIL: g++.dg/lto/20100302 cp_lto_20100302_0.o-cp_lto_20100302_1.o link, -flto -fabi-version=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62061 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- The failure doesn't occur anymore, presumably fixed.
[Bug lto/63409] New: [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63409 Bug ID: 63409 Summary: [5 Regression] FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr -fno-linker-plugin Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com This can be triggered on Fedora20 with: make check-c++ RUNTESTFLAGS=--target_board=unix/-fno-use-linker-plugin lto.exp=pr63270_?.C spawn -ignore SIGHUP /ssd/uros/gcc-build/gcc/testsuite/g++/../../xg++ -B/ssd/uros/gcc-build/gcc/testsuite/g++/../../ cp_lto_pr63270_0.o cp_lto_pr63270_1.o -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/uros/gcc-svn/trunk/libstdc++-v3/libsupc++ -I/home/uros/gcc-svn/trunk/libstdc++-v3/include/backward -I/home/uros/gcc-svn/trunk/libstdc++-v3/testsuite/util -fmessage-length=0 -flto -O2 -Wno-odr -L/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/ssd/uros/gcc-build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs -fno-use-linker-plugin -o g++-dg-lto-pr63270-01.exe cp_lto_pr63270_0.o: In function `v8::internal::fn1()': pr63270_0.C:(.text+0xa): undefined reference to `v8::internal::B::B(int)' pr63270_0.C:(.text+0x16): undefined reference to `v8::internal::B::B(int)' pr63270_0.C:(.text+0x22): undefined reference to `v8::internal::A::A(int)' pr63270_0.C:(.text+0x27): undefined reference to `v8::internal::G::m_fn1()' collect2: error: ld returned 1 exit status compiler exited with status 1 output is: cp_lto_pr63270_0.o: In function `v8::internal::fn1()': pr63270_0.C:(.text+0xa): undefined reference to `v8::internal::B::B(int)' pr63270_0.C:(.text+0x16): undefined reference to `v8::internal::B::B(int)' pr63270_0.C:(.text+0x22): undefined reference to `v8::internal::A::A(int)' pr63270_0.C:(.text+0x27): undefined reference to `v8::internal::G::m_fn1()' collect2: error: ld returned 1 exit status FAIL: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o link, -flto -O2 -Wno-odr UNRESOLVED: g++.dg/lto/pr63270 cp_lto_pr63270_0.o-cp_lto_pr63270_1.o execute -flto -O2 -Wno-odr
[Bug c++/63306] [4.9 Regression] ICE: Segmentation fault in analyze_functions()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63306 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 --- This got fixed on the trunk with r213425 aka PR61510.
[Bug ipa/63270] [5 Regression] internal compiler error: in odr_types_equivalent_p, at ipa-devirt.c:1075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63270 --- Comment #6 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to marxin from comment #5) Author: marxin Date: Mon Sep 22 09:39:20 2014 New Revision: 215451 URL: https://gcc.gnu.org/viewcvs?rev=215451root=gccview=rev Log: PR lto/63270 - new test * g++.dg/lto/pr63270_0.C: New test. * g++.dg/lto/pr63270_1.C: New test. The testcase fails with -fno-linker-plugin, please see PR 63409.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #2 from frankhb1989 at gmail dot com --- (In reply to Jonathan Wakely from comment #1) Which of macros are defined on mingw-w64? Preprocessing this should tell you #include chrono #ifdef _GLIBCXX_USE_CLOCK_REALTIME #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL #warning system_clock using syscall(SYS_clock_gettime, CLOCK_REALTIME, tp); #else #warning system_clock using clock_gettime(CLOCK_REALTIME, tp); #endif #elif defined(_GLIBCXX_USE_GETTIMEOFDAY) #warning system_clock using gettimeofday(tv, 0); #else #warning system_clock using std::time(0); #endif #ifdef _GLIBCXX_USE_CLOCK_MONOTONIC #ifdef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL #warning steady_clock using syscall(SYS_clock_gettime, CLOCK_MONOTONIC, tp); #else #warning steady_clock using clock_gettime(CLOCK_MONOTONIC, tp); #endif #else #warning steady_clock using time_point(system_clock::now().time_since_epoch()); #endif I've looked into c++config.h and I'm sure mingw-w64 4.9.1 distro of msys2 uses clock_gettime defined in winpthreads: /* Defined if clock_gettime syscall has monotonic and realtime clock support. */ /* #undef _GLIBCXX_USE_CLOCK_GETTIME_SYSCALL */ /* Defined if clock_gettime has monotonic clock support. */ #define _GLIBCXX_USE_CLOCK_MONOTONIC 1 /* Defined if clock_gettime has realtime clock support. */ #define _GLIBCXX_USE_CLOCK_REALTIME 1 /* Defined if gettimeofday is available. */ #define _GLIBCXX_USE_GETTIMEOFDAY 1 Here is the output (g++ -std=c++11): a.cc:7:2: warning: #warning system_clock using clock_gettime(CLOCK_REALTIME, tp); [-Wcpp] #warning system_clock using clock_gettime(CLOCK_REALTIME, tp); ^ a.cc:19:2: warning: #warning steady_clock using clock_gettime(CLOCK_MONOTONIC, tp); [-Wcpp] #warning steady_clock using clock_gettime(CLOCK_MONOTONIC, tp); ^
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #22 from Jan Hubicka hubicka at ucw dot cz ---
Doing it at same approximately the same place as loop header copying seems
to
make most sense to me. It benefits from early cleanups and DCE definitly
and
it should enable more fun with the later scalar passes that are almost all
rerun then.
We need to make sure tracer doesn't mess too much with loops then.
Btw, useless tracing may be undone again by tail-merging.
Tracer already does:
/* We have the tendency to duplicate the loop header
of all do { } while loops. Do not do that - it is
not profitable and it might create a loop with multiple
entries or at least rotate the loop. */
bb2-loop_father-header != bb2)
so it won't kill natural loops and peel (I should find time to update the
peeling pass). It also has:
if (bb_seen_p (bb2) || (e-flags (EDGE_DFS_BACK | EDGE_COMPLEX))
|| find_best_successor (bb2) != e)
break;
to not unroll. So i think it is safe for loop optimizer - all it can do
is expanding a loop that has control flow in it reducing its unrollability
later.
Tracer seems to consume only profile information and thus doesn't
rely on any other transforms (well, apart from cleanups which could
affect its cost function). Why not schedule it even earlier?
Like to before pass_build_alias? (the pipeline up to loop transforms
is quite a mess...)
It uses profile information and code size estiamtes. I expect that (especially
for C++ stuff) the early post inline passes will remove a lot of code and thus
improve traceability. This is why I looked for spot after first DCE/DSE.
David, can you please be more specific about how you tested? Was it with
profile feedback? What about code size metrics?
Honza
[Bug rtl-optimization/32629] missing CSE for constant in registers / inefficient memset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32629 --- Comment #6 from Jan Hubicka hubicka at ucw dot cz --- We could also make $0 a not legitimate constant on x86... (and undo that late with a peephole2) I tried that in 90's. At that time it increased register pressure and was not win... Honza
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #33 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Sep 29 16:47:31 2014 New Revision: 215685 URL: https://gcc.gnu.org/viewcvs?rev=215685root=gccview=rev Log: 2014-09-29 Charles Baylis charles.bay...@linaro.org Backport from mainline r212303 PR target/49423 * config/arm/arm-protos.h (arm_legitimate_address_p, arm_is_constant_pool_ref): Add prototypes. * config/arm/arm.c (arm_legitimate_address_p): Remove static. (arm_is_constant_pool_ref) New function. * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6, arm_zero_extendqisi2_v6): Use Uh constraint for memory operand. (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory operand and remove pool_range and neg_pool_range attributes. (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove pool_range and neg_pool_range attributes. * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow constant pool references. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/arm/arm-protos.h branches/gcc-4_9-branch/gcc/config/arm/arm.c branches/gcc-4_9-branch/gcc/config/arm/arm.md branches/gcc-4_9-branch/gcc/config/arm/constraints.md
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #34 from cbaylis at gcc dot gnu.org --- Author: cbaylis Date: Mon Sep 29 17:07:47 2014 New Revision: 215686 URL: https://gcc.gnu.org/viewcvs?rev=215686root=gccview=rev Log: 2014-09-29 Charles Baylis charles.bay...@linaro.org Backport from mainline r212303 PR target/49423 * config/arm/arm-protos.h (arm_legitimate_address_p, arm_is_constant_pool_ref): Add prototypes. * config/arm/arm.c (arm_legitimate_address_p): Remove static. (arm_is_constant_pool_ref) New function. * config/arm/arm.md (unaligned_loadhis, arm_zero_extendhisi2_v6, arm_zero_extendqisi2_v6): Use Uh constraint for memory operand. (arm_extendhisi2, arm_extendhisi2_v6): Use Uh constraint for memory operand and remove pool_range and neg_pool_range attributes. (arm_extendqihi_insn, arm_extendqisi, arm_extendqisi_v6): Remove pool_range and neg_pool_range attributes. * config/arm/constraints.md (Uh): New constraint. (Uq): Don't allow constant pool references. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/arm/arm-protos.h branches/gcc-4_8-branch/gcc/config/arm/arm.c branches/gcc-4_8-branch/gcc/config/arm/arm.md branches/gcc-4_8-branch/gcc/config/arm/constraints.md
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- What libstdc++ is doing is sensible, why is the realtime clock so much coarser than the monotonic clock on mingw-w64?
[Bug target/49423] [4.8/4.9/5 Regression] [arm] internal compiler error: in push_minipool_fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 cbaylis at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #35 from cbaylis at gcc dot gnu.org --- Backports committed to 4.8 and 4.9
[Bug plugins/63410] New: [Regression] pass_instances.def is not installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63410 Bug ID: 63410 Summary: [Regression] pass_instances.def is not installed Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Created attachment 33614 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33614action=edit Trivial patch to add pass-instances.def to installed headers We install the header pass_manager.h, but it can't be included by a plugin, since it includes pass-instances.def, and we don't current install that. /home/david/coding/gcc-python/gcc-svn-4.9/install/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/plugin/include/pass_manager.h:123:30: fatal error: pass-instances.def: No such file or directory #include pass-instances.def Affects 4.9 branch (e.g. r215685), and, I believe, trunk. Marking as [Regression] since this currently makes it impossible to access the roots of the pass tree (all_passes et al) from a plugin in 4.9+, since they were moved from being globals to being member data of the pass_manager in 4.9, hence we need to include pass_manager.h for that. (My fault, sorry: I was the one who moved these from being globals to being member data. The gcc-python-plugin needs this, and hence this is one thing blocking that plugin from being built against 4.9) Am currently verifying the obvious patch.
[Bug target/63408] GCC emits incorrect FMA instruction on Cortex-M4 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- Are you sure 1120403456 does not encode -100.0 ?
[Bug target/61407] Build errors on latest OS X 10.10 Yosemite with Xcode 6 on GCC 4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407 --- Comment #41 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Mon Sep 29 18:40:57 2014 New Revision: 215690 URL: https://gcc.gnu.org/viewcvs?rev=215690root=gccview=rev Log: PR target/61407 * config/darwin-c.c (version_as_macro): Added extra 0 for OS X 10.10 and above. * config/darwin-driver.c (darwin_find_version_from_kernel): Removed kernel version check to avoid incrementing it after every major OS X release. (darwin_default_min_version): Avoid static memory buffer. * gcc.dg/darwin-minversion-1.c: Fixed formatting * gcc.dg/darwin-minversion-2.c: Fixed formatting * gcc.dg/darwin-minversion-3.c: Fixed formatting * gcc.dg/darwin-minversion-4.c: Added test for OS X 10.10 Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-4.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/darwin-c.c branches/gcc-4_9-branch/gcc/config/darwin-driver.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-2.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/darwin-minversion-3.c
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 Pat Haugen pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #6 from Pat Haugen pthaugen at gcc dot gnu.org --- (In reply to Jiong Wang from comment #5) we need to check the following else if (GET_CODE == CLOBBER || GET_CODE (x) == USE || GET_CODE (x) == ASM_INPUT) I will post the fix after pass x86 bootstrap and regression r215563 also introduced a miscompare on PowerPC for cpu2000 benchmark 254.gap. Applying your patch proposed on the gcc-patches ml for this bug fixes the issue.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #7 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to Pat Haugen from comment #6) (In reply to Jiong Wang from comment #5) we need to check the following r215563 also introduced a miscompare on PowerPC for cpu2000 benchmark 254.gap. Applying your patch proposed on the gcc-patches ml for this bug fixes the issue. thanks for reporting this, sorry for causing trouble.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #8 from Jiong Wang jiwang at gcc dot gnu.org --- (In reply to Pat Haugen from comment #6) (In reply to Jiong Wang from comment #5) we need to check the following else if (GET_CODE == CLOBBER || GET_CODE (x) == USE || GET_CODE (x) == ASM_INPUT) I will post the fix after pass x86 bootstrap and regression r215563 also introduced a miscompare on PowerPC for cpu2000 benchmark 254.gap. Applying your patch proposed on the gcc-patches ml for this bug fixes the issue. and I am curious about whether there are any performance change since this insn sink change.
[Bug c/38716] Undocumented __attribute__((optimize)) behaviour when the attribute specifies no optimisation level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-29 CC||fxcoudert at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/63408] GCC emits incorrect FMA instruction on Cortex-M4 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63408
--- Comment #2 from Itay Perl itay at phobotic dot com ---
Yes, I am certain.
1. Replacing the minus sign with a plus sign results in the same code
(including the constant)
2.
struct.unpack('I', struct.pack('f', 100))[0]
1120403456
[Bug middle-end/35545] tracer pass is run too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35545
--- Comment #23 from davidxl xinliangli at gmail dot com ---
(In reply to Jan Hubicka from comment #22)
Doing it at same approximately the same place as loop header copying
seems to
make most sense to me. It benefits from early cleanups and DCE definitly
and
it should enable more fun with the later scalar passes that are almost all
rerun then.
We need to make sure tracer doesn't mess too much with loops then.
Btw, useless tracing may be undone again by tail-merging.
Tracer already does:
/* We have the tendency to duplicate the loop header
of all do { } while loops. Do not do that - it is
not profitable and it might create a loop with multiple
entries or at least rotate the loop. */
bb2-loop_father-header != bb2)
so it won't kill natural loops and peel (I should find time to update the
peeling pass). It also has:
if (bb_seen_p (bb2) || (e-flags (EDGE_DFS_BACK | EDGE_COMPLEX))
|| find_best_successor (bb2) != e)
break;
to not unroll. So i think it is safe for loop optimizer - all it can do
is expanding a loop that has control flow in it reducing its unrollability
later.
Tracer seems to consume only profile information and thus doesn't
rely on any other transforms (well, apart from cleanups which could
affect its cost function). Why not schedule it even earlier?
Like to before pass_build_alias? (the pipeline up to loop transforms
is quite a mess...)
It uses profile information and code size estiamtes. I expect that
(especially
for C++ stuff) the early post inline passes will remove a lot of code and
thus
improve traceability. This is why I looked for spot after first DCE/DSE.
David, can you please be more specific about how you tested? Was it with
profile feedback? What about code size metrics?
It is with profile feedback. There is also reduction in code size, though very
tiny change.
David
Honza
[Bug inline-asm/62144] Frame pointer required, but reserved error with -fomit-frame-pointer but only with -m32 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62144 --- Comment #2 from Brooks Moses brooks at gcc dot gnu.org --- Ping? Any updates on this?
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400
--- Comment #4 from frankhb1989 at gmail dot com ---
(In reply to Jonathan Wakely from comment #3)
What libstdc++ is doing is sensible, why is the realtime clock so much
coarser than the monotonic clock on mingw-w64?
It is not always true that the real time clock would have a higher resolution
than monotonic clock. At least I found nothing about resolution guaranteed by
POSIX, in fact, clock resolutions are implementation-defined.
With mingw-w64, the following program shows that the monotonic clock is far
more precise:
#include pthread_time.h
#include iostream
int main()
{
using namespace std;
timespec ts;
if(clock_getres(CLOCK_REALTIME, ts) == 0)
cout CLOCK_REALTIME: ts.tv_sec ',' ts.tv_nsec endl;
if(clock_getres(CLOCK_MONOTONIC, ts) == 0)
cout CLOCK_MONOTONIC: ts.tv_sec ',' ts.tv_nsec endl;
}
The result on my machine:
CLOCK_REALTIME: 0,15625000
CLOCK_MONOTONIC: 0,489
I then found the actual implementation in winpthreads (clock.c):
int clock_gettime(clockid_t clock_id, struct timespec *tp)
{
unsigned __int64 t;
LARGE_INTEGER pf, pc;
union {
unsigned __int64 u64;
FILETIME ft;
} ct, et, kt, ut;
switch(clock_id) {
case CLOCK_REALTIME:
{
GetSystemTimeAsFileTime(ct.ft);
t = ct.u64 - DELTA_EPOCH_IN_100NS;
tp-tv_sec = t / POW10_7;
tp-tv_nsec = ((int) (t % POW10_7)) * 100;
return 0;
}
case CLOCK_MONOTONIC:
{
if (QueryPerformanceFrequency(pf) == 0)
return lc_set_errno(EINVAL);
if (QueryPerformanceCounter(pc) == 0)
return lc_set_errno(EINVAL);
tp-tv_sec = pc.QuadPart / pf.QuadPart;
tp-tv_nsec = (int) (((pc.QuadPart % pf.QuadPart) * POW10_9 +
(pf.QuadPart 1)) / pf.QuadPart);
if (tp-tv_nsec = POW10_9) {
tp-tv_sec ++;
tp-tv_nsec -= POW10_9;
}
return 0;
}
case CLOCK_PROCESS_CPUTIME_ID:
{
if(0 == GetProcessTimes(GetCurrentProcess(), ct.ft, et.ft, kt.ft,
ut.ft))
return lc_set_errno(EINVAL);
t = kt.u64 + ut.u64;
tp-tv_sec = t / POW10_7;
tp-tv_nsec = ((int) (t % POW10_7)) * 100;
return 0;
}
case CLOCK_THREAD_CPUTIME_ID:
{
if(0 == GetThreadTimes(GetCurrentThread(), ct.ft, et.ft, kt.ft,
ut.ft))
return lc_set_errno(EINVAL);
t = kt.u64 + ut.u64;
tp-tv_sec = t / POW10_7;
tp-tv_nsec = ((int) (t % POW10_7)) * 100;
return 0;
}
default:
break;
}
return lc_set_errno(EINVAL);
}
For CLOCK_REALTIME, the Windows API GetSystemTimeAsFileTime is used.
GetSystemTimePreciseAsFileTime is an improved version which provide the
highest possible level of precision (1us). Unfortunately, the latter is only
available since Windows 8/Windows 2012, which is not suited for winpthreads for
compatibility reason IMO. See this MSDN page for details:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh706895(v=vs.85).aspx
For CLOCK_MONOTONIC, QPC(Query Performance Counter) APIs are used. This method
is reasonably portable (among different versions of Windows, since Windows
2000), and Microsoft strongly suggested it when high-resolution time stamps
needed, see
http://msdn.microsoft.com/en-us/library/windows/desktop/dn553408(v=vs.85).aspx.
However, QPC is not suited for a system-wide clock.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- For the record the test gfortran.dg/typebound_operator_3.f03 also failed with -O1 and -m64 (see https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00226.html). This is fixed by the patch at https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02568.html.
[Bug libstdc++/63400] [C++11]precision of std::chrono::high_resolution_clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63400 --- Comment #5 from frankhb1989 at gmail dot com --- BTW, what if the clock_gettime call failed? The current implementation does nothing about error handling... (Though for QPC on Windows it should rarely fail for machines within a decade.)
[Bug libstdc++/62313] Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 --- Comment #12 from François Dumont fdumont at gcc dot gnu.org --- Author: fdumont Date: Mon Sep 29 21:22:17 2014 New Revision: 215693 URL: https://gcc.gnu.org/viewcvs?rev=215693root=gccview=rev Log: 2014-09-29 François Dumont fdum...@gcc.gnu.org PR libstdc++/62313 * include/debug/safe_base.h (_Safe_iterator_base(const _Safe_iterator_base)): Delete declaration. (_Safe_iterator_base operator=(const _Safe_iterator_base)): Likewise. * include/debug/safe_iterator.h (_Safe_iterator): Move normal iterator before _Safe_iterator_base in memory. Lock before modifying the iterator in numerous places. * include/debug/safe_local_iterator.h (_Safe_local_iterator_base(const _Safe_local_iterator_base)): Delete declaration. (_Safe_local_iterator_base operator=(const _Safe_local_iterator_base)): Likewise. * include/debug/safe_unordered_base.h (_Safe_local_iterator): Move normal iterator before _Safe_iterator_base in memory. Lock before modifying the iterator in numerous places. * include/debug/forward_list (_Safe_forward_list::_M_swap_aux): Adapt. * include/debug/safe_sequence.tcc (_Safe_sequence::_M_transfer_from_if): Adapt. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/debug/forward_list trunk/libstdc++-v3/include/debug/safe_base.h trunk/libstdc++-v3/include/debug/safe_iterator.h trunk/libstdc++-v3/include/debug/safe_local_iterator.h trunk/libstdc++-v3/include/debug/safe_sequence.tcc trunk/libstdc++-v3/include/debug/safe_unordered_base.h
[Bug libstdc++/62313] Data race in debug iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62313 François Dumont fdumont at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #13 from François Dumont fdumont at gcc dot gnu.org --- A number of additional locks have been added to make sure we do not modify an iterator while the list of iterators might be checked through another thread.
[Bug tree-optimization/63411] New: [4.9/5 regression] ivopt produces wrong struct offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411
Bug ID: 63411
Summary: [4.9/5 regression] ivopt produces wrong struct offset
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: critical
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Host: i686-linux-gnu
Target: sh*-*-*
Compiling the following as C or C++:
typedef struct
{
unsigned char sprindex;
unsigned char y;
unsigned char index;
unsigned char attr;
unsigned char x;
unsigned short pattern;
} oam;
extern oam OAM3[8];
int test2 (unsigned c, int r)
{
for (unsigned i = 0; i c; ++i)
{
oam* s = (OAM3[i]);
if (s-attr 0x40)
r += s-pattern;
}
return r;
}
on SH (big or little endian, any CPU type) with -O2 results in the following
wrong code:
_test2:
tst r4,r4
bt .L12
mov.l .L14,r1
.align 2
.L4:
mov.b @r1,r0
tst #64,r0
bt/s.L3
mov r1,r2
add #3,r2 wrong struct offset '3'
mov.w @r2,r2 should be '3*2', i.e. '6'.
extu.w r2,r2
add r2,r5
.L3:
dt r4
bf/s.L4
add #8,r1
.L12:
rts
mov r5,r0
.L15:
.align 2
.L14:
.long _OAM3+3
.size _test2, .-_test2
.ident GCC: (GNU) 4.9.2 20140929 (prerelease)
Disabling ivopt with '-fno-ivopts' produces correct code:
_test2:
tst r4,r4
bt .L12
mov #0,r2
mov.l .L14,r3
.align 2
.L4:
mov r2,r1
shll2 r1
add r1,r1
add r3,r1
mov.b @(3,r1),r0
tst #64,r0
bt .L3
mov.w @(6,r1),r0 correct struct offset '6'
extu.w r0,r1
add r1,r5
.L3:
dt r4
bf/s.L4
add #1,r2
.L12:
rts
mov r5,r0
.L15:
.align 2
.L14:
.long _OAM3
.size _test2, .-_test2
.ident GCC: (GNU) 4.9.2 20140929 (prerelease)
I haven't checked whether this happens on other targets, but I guess this is
not SH specific.
This happens on the current 4.9 branch and trunk. 4.8 branch is not affected.
[Bug tree-optimization/63411] [4.9/5 regression] ivopt produces wrong struct offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63411 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||amker.cheng at gmail dot com, ||ebotcazou at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org --- CC'ing some people who have recently worked on tree-ssa-loop-ivopts.c according to the 4.9 changelog.
[Bug c++/53025] [C++11] noexcept operator depends on copy-elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53025
Paolo Carlini paolo.carlini at oracle dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-09-29
Ever confirmed|0 |1
--- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com ---
In case we need something more for templates, eg:
templatetypename T
struct A {
A() noexcept {}
A(const A) noexcept(false) {}
};
templatetypename T
void a(AT) noexcept {}
templatetypename T
void f()
{
static_assert(!noexcept(a(AT{})), ); // Error
}
void g()
{
fint();
}
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #46 from Oleg Endo olegendo at gcc dot gnu.org --- newlib 1.2.0 now builds without errors here.
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #47 from Oleg Endo olegendo at gcc dot gnu.org ---
Created attachment 33615
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33615action=edit
reduced CSiBE /libpng-1.2.5 test
I've tried compiling CSiBE (-m4 -ml). This is a stripped down pngrutil.c which
crashes in lra-spills.c (remove_pseudos).
It's a bit strange, because if the function 'test' (top of the file) is
compiled before the actual problematic function 'png_handle_cHRM', there's a
segfault. If 'test' is left out, it ends in:
internal compiler error: in copy_rtx, at rtl.c:356
0x862e4d2 copy_rtx(rtx_def*)
../../gcc-sh-lra/gcc/rtl.c:356
In the segfault case, the insn is:
insn =
(call_insn 617 775 618 42 (parallel [
(call (mem:SI (reg/f:SI 701) [0 png_set_cHRM S4 A32])
(const_int 0 [0]))
(use (reg:PSI 151 ))
(clobber (reg:SI 146 pr))
]) sh_tmp.cpp:395 316 {calli}
(expr_list:REG_DEAD (reg:SI 69 fr5)
(expr_list:REG_DEAD (reg:SI 75 fr11)
(expr_list:REG_DEAD (reg:SI 71 fr7)
(expr_list:REG_DEAD (reg:SI 73 fr9)
(expr_list:REG_DEAD (reg/f:SI 701)
(expr_list:REG_DEAD (reg:SI 5 r5)
(expr_list:REG_DEAD (reg:SI 4 r4)
(expr_list:REG_DEAD (reg:DF 74 fr10)
(expr_list:REG_DEAD (reg:DF 72 fr8)
(expr_list:REG_DEAD (reg:DF 70 fr6)
(expr_list:REG_DEAD (reg:DF 68 fr4)
(expr_list:REG_CALL_DECL
(symbol_ref:SI (png_set_cHRM) [flags 0x41] function_decl 0xb7407c80
png_set_cHRM)
(nil)
(expr_list:SI (use (reg:SI 4 r4))
(expr_list:SI (use (reg:SI 5 r5))
(expr_list:DF (use (reg:DF 68 fr4))
(expr_list:DF (use (reg:DF 70 fr6))
(expr_list:DF (use (reg:DF 72 fr8))
(expr_list:DF (use (reg:DF 74 fr10))
(expr_list:DF (use (mem:DF (reg/f:SI 15 r15) [0 S8
A32]))
(expr_list:DF (use (mem:DF (reg/f:SI 699) [0
S8 A32]))
(expr_list:DF (use (mem:DF (reg/f:SI 696)
[0 S8 A32]))
(expr_list:DF (use (mem:DF (reg/f:SI
693) [0 S8 A32]))
(nil
and the crash is caused by
loc = (reg/f:SI 699)
In the non-segfault case the input arg 'orig' in copy_rtx prints (UnKnown
Unknown)
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 Sandra Loosemore sandra at codesourcery dot com changed: What|Removed |Added CC||sandra at codesourcery dot com --- Comment #17 from Sandra Loosemore sandra at codesourcery dot com --- I'm seeing segfaults from pr61160-2.C and pr61160-3.C on arm-none-linux-gnueabi with -mthumb -- probably the same trouble reported by Christophe earlier. I believe this is a binutils issue. I reported the details here: https://sourceware.org/bugzilla/show_bug.cgi?id=17444
[Bug target/55212] [SH] Switch from IRA to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #48 from Oleg Endo olegendo at gcc dot gnu.org --- (In reply to Oleg Endo from comment #47) Created attachment 33615 [details] reduced CSiBE /libpng-1.2.5 test I've tried compiling CSiBE (-m4 -ml). This is a stripped down pngrutil.c which crashes in lra-spills.c (remove_pseudos). It's a bit strange, because if the function 'test' (top of the file) is compiled before the actual problematic function 'png_handle_cHRM', there's a segfault. The segfault happens because of this lookup (remove_pseudos): if ((hard_reg = spill_hard_reg[i]) != NULL_RTX) The array at i = 699 doesn't seem to contain anything valid. Function 'assign_spill_hard_regs' sets those values: spill_hard_reg[regno] = gen_raw_REG (PSEUDO_REGNO_MODE (regno), hard_regno); However, in this case it never gets to it because of this: if (! lra_reg_spill_p) return n;
[Bug c++/63412] New: aliasing issue exposed by inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412
Bug ID: 63412
Summary: aliasing issue exposed by inlining
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: doug.gilmore at imgtec dot com
Created attachment 33616
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33616action=edit
test program
The attached test program fails with 4.7 up to ToT at -O2 on both x86
(I built x86_64 with the -m32 multi-lib variant) and MIPS.
$ g++ -Wall -g -m32 -std=gnu++11 -O2 -fno-exceptions bad_i5.c -static -o la
-save-temps ./la
Aborted (core dumped)
$ g++ -Wall -g -m32 -std=gnu++11 -O0 -fno-exceptions bad_i5.c -static -o la
-save-temps ./la
$
Note that simplifying one of the expressions makes the program work:
$ g++ -Wall -g -DNO_VOL -m32 -std=gnu++11 -O2 -fno-exceptions bad_i5.c -static
-o la -save-temps ./la
$
The generated code has the store below the implicit
load in the compare:
cmpl%ebx, 4(%esp,%edx,4)
movl%eax, 4(%esp)
jne.L5
which is incorrect. It should be:
movl%eax, 4(%esp)
cmpl%ebx, 4(%esp,%edx,4)
jne.L5
We have an internal debate on what the issue is.
Some are of the opinion that casting is breaking alias rules and
thus the behavior of the program is undefined.
Thus something along the lines the following changes are needed.
$ diff bad_i5{,_mod}.c
48c48
return reference_-AsMirrorPtr();
---
return static_castT*(reference_-AsMirrorPtr());
50c50
ObjectReferenceT* reference_;
---
ObjectReferenceObject* reference_;
52,53c52,53
: reference_(reinterpret_castObjectReferenceT*(reference))
{ }
---
: reference_((reference))
{ }
$ g++ -g -m32 -std=gnu++11 -O2 -fno-exceptions bad_i5_mod.c -static -o la
-save-temps ./la
$
If there is a strict aliasing issue, shouldn't -Wall be warning about
it?
My take is that the casting is not a concern here since the returns
(and entries) from the inlined routines effectively sequences the
problematic store to be above the problematic load, and thus should
be considered a bug in GCC.
[Bug c++/63412] aliasing issue exposed by inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412 --- Comment #1 from Doug Gilmore doug.gilmore at imgtec dot com --- Created attachment 33617 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33617action=edit Modified version where type casts are modified.
[Bug c++/63412] aliasing issue exposed by inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63412 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- If there is a strict aliasing issue, shouldn't -Wall be warning about it? Well sometimes it is hard to detect strict aliasing rules violations. And yes this is an alias violation as ObjectReferenceArray and ObjectReferenceObject are two different classes and will be in two different aliasing sets.
[Bug rtl-optimization/63259] Detecting byteswap sequence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63259 --- Comment #4 from thopre01 at gcc dot gnu.org --- I detect no noticeable difference when bootstrapping gcc with or without the patch so I think we're in for a fix. :-)
