[Bug ada/59853] gnatmake cannot build a library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59853 --- Comment #4 from Sylvain Laperche sylvain.laperche at gmail dot com --- I downloaded the source of GCC 4.8.2 from here[1]. I compiled it with and without --disable-nls, in both case it works fine. I cannot reproduce the issue I encounter with the the binary from the official repository of Archlinux. That seems to be an issue related to my environment or to the packaging done by the distribution. [1]: http://ftp.gnu.org/gnu/gcc/gcc-4.8.2/gcc-4.8.2.tar.bz2
[Bug target/49423] [4.7/4.8/4.9 Regression] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #21 from Yury Gribov y.gribov at samsung dot com --- Can we accept Julian's patch for 4.9? This bug really hurts.
[Bug target/49423] [4.7/4.8/4.9 Regression] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #22 from Eric Botcazou ebotcazou at gcc dot gnu.org --- IMO this bug should be moved to P1 as a regression on a primary platform and the RMs should up the pressure on the maintainers to have it fixed.
[Bug rtl-optimization/59857] 4.8.2 loop optimization is worse than 4.5.1 under ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59857
--- Comment #3 from Jacky Ko xuelingko at yahoo dot com.tw ---
You are right. ulv is volatile, the typedef in the code is
typedef unsigned int volatile ulv;
I'm sorry that I didn't provide the definition.
I modify the C code as below,
int TEST_Memread(unsigned int * pSrc, volatile unsigned int *pDst, unsigned int
nCount)
{
unsigned int *p1 = NULL;
unsigned int i;
p1 = (unsigned int *) pSrc;
for (i = 0; i nCount; i++)
*pDst = *p1++;
return 0;
}
After testing it, the performance is the same between 4.5.1 and 4.8.2. If the
pointer is not a volatile type, both version will do load address data and
post-increment operations in one instruction.
[Bug target/49423] [4.7/4.8/4.9 Regression] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org --- IMHO a bug that is known for 2.5 years and unfixed shouldn't be all of sudden P1. That doesn't mean the maintainers should ignore the bug, just that it isn't a release blocker.
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
--- Comment #6 from algrant at acm dot org ---
Here is a complete C++11 test case. The code generated for the two loads
in thread B doesn't maintain the required ordering:
...
ldrbw1, [x0]
uxtbw1, w1
adrpx0, .LANCHOR0
ldr w2, [x3]
...
According to the architecture specification, to achieve the ordering it's
sufficient to use the result of the first load in the calculation of the
address of the second, even if it's done in such a way as to have no
dependence on the value.
/* Reproducer for 59448: compile with -std=c++11 -lpthread */
#include atomic
#include thread
#include stdio.h
#include assert.h
static std::atomicbool flag(0);
static int data;
/*
Thread A tries to release a data value 1 to thread B via a
release/consume sequence.
In the demonstration, this is tried repeatedly. The iterations of
the two threads are synchronized via a release/acquire sequence
from B to A. This is not relevant to the ordering problem.
*/
void threadA(void)
{
for (;;) {
data = 1; // A.A
flag.store(1, std::memory_order_release); // A.B
/* By 1.9#14, A.A is sequenced before A.B */
/* Now wait for thread B to accept the data. */
while (flag.load(std::memory_order_acquire) == 1);
assert(data == 0);
}
}
void threadB(void)
{
for (;;) {
int f, d;
do {
f = flag.load(std::memory_order_consume); // B.A
d = *(data + f - f); // B.B
/* By 1.10#9, B.A carries a dependency to B.B */
/* By 1.10#10, A.B is dependency-ordered before B.B */
/* By 1.10#11, A.A intra-thread happens before B.B */
/* By 1.10#12, A.A happens before B.B */
/* By 1.10#13, A.A is a visible side-effect with respect to B.B
and the value determined by B.B shall be the
value (1) stored by A.A. */
} while (!f);
assert(d == 1);
/* Release thread A to start another iteration. */
data = 0;
flag.store(0, std::memory_order_release);
}
}
int main(void)
{
std::thread a(threadA);
std::thread b(threadB);
a.join();
b.join();
return 0;
}
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- *(data + f - f); This could be undefined behavior if f is not 0 or 1.
[Bug c++/59868] Extremely slow compile times with -g (var-tracking)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59868 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog Summary|Extremely slow compile |Extremely slow compile |times |times with -g ||(var-tracking) --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Or -fno-var-tracking.
[Bug c++/59865] gnu multiversion calculates wrong target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59865 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-20 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- What's the target you are running on? Please provide /proc/cpuinfo output.
[Bug tree-optimization/59757] Unexpected VN_TOP in SSCVN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59757 Joey Ye joey.ye at arm dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Joey Ye joey.ye at arm dot com --- This is most likely a bug in mingw32 build for GCC 4.2.1, which is the compiler that I used to build GCC running on Windows. If GCC is built with -O0 it passes without this ICE. Switching to later version of mingw32 tools solves it.
[Bug c/59863] const array in function is placed on stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- This is also simply a gimplification issue. For larger arrays we initialize the stack with an aggregate copy from the constant pool.
[Bug target/49423] [4.7/4.8/4.9 Regression] [arm] internal compiler error: in push_minipool_fix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49423 --- Comment #24 from Eric Botcazou ebotcazou at gcc dot gnu.org --- IMHO a bug that is known for 2.5 years and unfixed shouldn't be all of sudden P1. That doesn't mean the maintainers should ignore the bug, just that it isn't a release blocker. I'm afraid that history has shown that you won't achieve the former without doing the latter...
[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I'd say it's a bug in cloog. Or a bug in our documentation which could be clearer.
[Bug c++/59885] New: compiler issues incorrect ambiguous base class error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59885
Bug ID: 59885
Summary: compiler issues incorrect ambiguous base class error
message
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burrows.labs at gmail dot com
The following code produces an error message that I believe to have swapped the
'base' and 'derived' class.
#include iostream
template typename... Whatever
class A;
template typename Type
class AType {};
template typename Type, typename Head, typename... Tail
class AType, Head, Tail... : AType, Tail... {};
class B : public Aint, int, double {};
template typename Type, typename... Unused
void f(AType, Unused... *ref)
{
std::cout f.a std::endl;
}
int
main()
{
B *b = new B;
f(b);
return 0;
}
// eof
$ g++-4.7 -std=c++0x -pedantic -Wall in.cpp -o in
in.cpp: In function ‘int main()’:
in.cpp:24:8: error: no matching function for call to ‘f(B*)’
in.cpp:24:8: note: candidate is:
in.cpp:15:6: note: templateclass Type, class ... Unused void f(AType, Unused
...*)
in.cpp:15:6: note: template argument deduction/substitution failed:
in.cpp:24:8: note: ‘B’ is an ambiguous base class of ‘AType, Unused ...’
[Bug target/59874] Missing builtin (__builtin_clzs) when compiling with g++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59874 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-* Component|c++ |target --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- It seems #pragma GCC push_options #pragma GCC target(lzcnt) from lzcntintrin.h doesn't work with C++?
[Bug lto/55113] ICE with LTO and -fshort-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #11 from Richard Biener rguenth at gcc dot gnu.org ---
If double_type_node is FE dependent then it needs treatment in
tree-streamer.c:preload_common_nodes:
static void
preload_common_nodes (struct streamer_tree_cache_d *cache)
{
unsigned i;
for (i = 0; i itk_none; i++)
/* Skip itk_char. char_type_node is dependent on -f[un]signed-char. */
if (i != itk_char)
record_common_node (cache, integer_types[i]);
for (i = 0; i stk_type_kind_last; i++)
record_common_node (cache, sizetype_tab[i]);
for (i = 0; i TI_MAX; i++)
/* Skip boolean type and constants, they are frontend dependent. */
if (i != TI_BOOLEAN_TYPE
i != TI_BOOLEAN_FALSE
i != TI_BOOLEAN_TRUE)
record_common_node (cache, global_trees[i]);
}
[Bug ipa/59882] [4.9 Regression] internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59882 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug c/59863] const array in function is placed on stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59863 --- Comment #4 from Samuel Tardieu sam at gcc dot gnu.org --- Note that clang has this bug in reverse: it unifies the arrays even when recursive calls are possible and address escapes the defining function (http://llvm.org/bugs/show_bug.cgi?id=18557).
[Bug c++/59868] Extremely slow compile times with -g (var-tracking)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59868 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-20 Ever confirmed|0 |1 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- With plain -O1 we also get alias stmt walking : 14.78 (19%) usr 0.10 ( 6%) sys 14.90 (19%) wall 0 kB ( 0%) ggc tree SSA incremental: 31.81 (41%) usr 0.01 ( 1%) sys 31.82 (40%) wall 6645 kB ( 1%) ggc ick. Similar to old KDE testcases with a very big initializer function. Here it is 3 lines gli_init_gl_entrypoint_descs (I suppose auto-generated). From a quick look it's a single gigantic basic-block doing a sequence of global stores.
[Bug target/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jan 20 09:52:21 2014 New Revision: 206792 URL: http://gcc.gnu.org/viewcvs?rev=206792root=gccview=rev Log: PR target/59880 * config/i386/i386.c (ix86_avoid_lea_for_addr): Return false if operands[1] is a REG or ZERO_EXTEND of a REG. * gcc.target/i386/pr59880.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr59880.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/59880] ix86_avoid_lea_for_addr is buggy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59880 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jakub at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed for 4.9+.
[Bug middle-end/58479] [4.9 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Or rather -fvar-tracking-assignments. The slowness creeps in
trivially dead code : 0.37 (13%) usr 0.00 ( 0%) sys 0.37 (10%) wall
0 kB ( 0%) ggc
complete unrolling : 0.36 (13%) usr 0.53 (55%) sys 0.81 (22%) wall
211254 kB (38%) ggc
expand : 0.29 (10%) usr 0.09 ( 9%) sys 0.38 (10%) wall
346562 kB (62%) ggc
var-tracking itself doesn't enter the picture.
main ()
{
bb 2:
# DEBUG D#1 = f
# DEBUG t$0$0$0 = D#1
# DEBUG t$0$0$1 = D#1
# DEBUG t$0$0$2 = D#1
... 3.3 million (!) similar lines follow ...
e = 8;
d = 8;
c = 8;
b = 8;
a = 8;
return 0;
}
seems to be support for aggregate piece debug values makes this blow up
totally. Nobody is going to p t[][][] here (and I suspect gdb support
isn't ready here either).
[Bug rtl-optimization/57635] gcc hanging while compiling huge files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57635 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-20 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- We need some kind of a testcase for this, like preprocessed source of the file exhibiting the issue.
[Bug debug/57481] [4.8 Regression] LTO VTA compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57481 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-20 Known to work||4.9.0 Ever confirmed|0 |1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #8 from algrant at acm dot org --- I don't see how f can not be 0 or 1 here, but to make this even more clear that there is no UB, define flag this way: static std::atomicunsigned int flag(0); and calculate the address this way: d = *(data + (f - f)); // B.B The ordering requirements are the same, and there is no possibility of UB.
[Bug c++/59838] [4.7/4.8 Regression] ICE with an enum using an incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Jan 20 10:42:29 2014 New Revision: 206795 URL: http://gcc.gnu.org/viewcvs?rev=206795root=gccview=rev Log: PR c++/59838 cp/ * cvt.c (ocp_convert): Don't segfault on non-existing ENUM_UNDERLYING_TYPE. testsuite/ * g++.dg/diagnostic/pr59838.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/diagnostic/pr59838.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/cvt.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/59838] [4.7 Regression] ICE with an enum using an incomplete type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59838 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[4.7/4.8 Regression] ICE|[4.7 Regression] ICE with |with an enum using an |an enum using an incomplete |incomplete type |type --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed. (Not backporting it to 4.7.)
[Bug middle-end/58479] [4.9 Regression] slow var-tracking on x86_64-linux at -O1 (and above) with -g, but checking disabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58479
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
I don't see why do you think nobody would try to look at t[x][y][z] in the
debugger.
Anyway, I think we can do two things here. Obviously we can't give up on
cunrolling it because that would be a clear -fcompare-debug failure. But:
1) in loop unrolling, analyze the debug stmts we are about to unroll, and if
some of the debug stmts refer to a decl no other debug stmt in the loop refers
to (though would need to take into account DECL_DEBUG_EXPR overlaps) and the
expression in the debug stmt uses only SSA_NAMEs from before the loop,
constants and/or debug exprs from the loop that satisfy that recursively, just
emit the those debug stmts in the first iteration only and not repeat those in
all the other unrolled iterations
1a) alternatively to that, write some debug stmt optimization pass, that would
detect the case of useless debug stmts (saying something lives in what it is
known to live at from earlier debug stmts already)
2) have some debug stmt limits (--param controlled), above which we start
dropping debug stmts or resetting them just once or something similar. Because
it is possible that there are multiple debug stmts per the same decl in the
loop and 1) or 1a) can't do anything. Perhaps have the normal debug stmts in
first iteration of the unrolled loop (or a few of them, depending on how many
there are), then when we give up just reset all the debug stmts in some
iteration and after that iteration and before last iteration don't emit debug
stmts at all, then finally in the last iteration emit debug stmts again.
Testcase for 2) is e.g. -O2 -g:
int a, b, c, d, e;
int
main ()
{
for (a = 0; a 16; a++)
for (b = 0; b 16; b++)
for (c = 0; c 16; c++)
for (d = 0; d 16; d++)
for (e = 0; e 16; e++)
{
int f;
#define F10 f = 0; f = 1; f = 2; f = 3; f = 4; f = 5; f = 6; f = 7; f = 8; f =
9;
#define F100 F10 F10 F10 F10 F10 F10 F10 F10 F10 F10
F100
}
return 0;
}
Another testcase, with no unrolling at all, that shows that it is easy to get
thousands of debug stmts:
int a, b, c, d, e, f;
int
main ()
{
#define F1 {{f, f, f, f, f, f, f, f, f}, {f, f, f, f, f, f, f, f, f}},
#define F10 F1 F1 F1 F1 F1 F1 F1 F1 F1 F1
#define F100 F10 F10 F10 F10 F10 F10 F10 F10 F10 F10
#define F1000 F100 F100 F100 F100 F100 F100 F100 F100 F100 F100
int t[1000][2][9] = {
F1000
};
return 0;
}
not sure where if at all to put any --param limits here though, after all, you
get for this in the initializers as huge spaghetti code and only later on that
is transformed into no actual code, just DEBUG stmt spaghetti. Though,
supposedly this last example is already related to the PR59659 patch (which
I've done for C++ only so far).
[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org --- These invalid write/read disappear with r195140 (2013-01-14). I can confirm that I don't see any of these guys with current trunk. However I see a lot leak Yes, valgrind definitely reports a good number of leaks, also with current trunk. Unfortunately the test case is still quite a monstrosity ... Note that we have a couple of memleak PRs already, e.g.: * PR 38319 * PR 41936 * PR 55603 * PR 58557
[Bug c++/53958] set_slot_part and canon_value_cmp using 90% of compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53958 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- As usual, the iteration order imposed by pre_and_rev_postorder isn't the best one for a forward dataflow problem. Using inverted_post_order_compute improves compile-time somewhat. But I can still confirm variable tracking : 0.39 ( 1%) usr 0.00 ( 0%) sys 0.41 ( 1%) wall 5504 kB ( 6%) ggc var-tracking dataflow : 34.96 (84%) usr 0.16 (53%) sys 35.10 (84%) wall 47 kB ( 0%) ggc as general observation I wonder why the dataflow problem computes the _union_ as opposed to the intersection of the info on the preds in the !MAY_HAVE_DEBUG_INSNS case. Also if the MAY_HAVE_DEBUG_INSNS case really computes an intersection (as documented) then it can avoid repeated clearing of the in set and only needs to dataflow_set_merge from changed edges. Now the discrepancy in wrt the !MAY_HAVE_DEBUG_INSNS case makes me not trust that comment blindly ... That said, handling only changed edges can be done by doing the intersection in the if (changed) FOR_EACH_EDGE loop and dropping the initial -in set compute (just retaining the post-merge-adjust). From a quick look var-tracking doesn't seem to take the opportunity of pruning its sets based on variable scopes (it would need to compute scope liveness in vt_initialize). Anyway, here's a patch improving compile-time for this testcase by ~6% Index: gcc/var-tracking.c === --- gcc/var-tracking.c (revision 206599) +++ gcc/var-tracking.c (working copy) @@ -6934,12 +6934,12 @@ vt_find_locations (void) bool success = true; timevar_push (TV_VAR_TRACKING_DATAFLOW); - /* Compute reverse completion order of depth first search of the CFG + /* Compute reverse top sord order of the inverted CFG so that the data-flow runs faster. */ - rc_order = XNEWVEC (int, n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS); + rc_order = XNEWVEC (int, n_basic_blocks_for_fn (cfun)); bb_order = XNEWVEC (int, last_basic_block_for_fn (cfun)); - pre_and_rev_post_order_compute (NULL, rc_order, false); - for (i = 0; i n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS; i++) + int num = inverted_post_order_compute (rc_order); + for (i = 0; i num; i++) bb_order[rc_order[i]] = i; free (rc_order);
[Bug c++/53958] set_slot_part and canon_value_cmp using 90% of compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53958 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Richard Biener from comment #6) As usual, the iteration order imposed by pre_and_rev_postorder isn't the best one for a forward dataflow problem. Using inverted_post_order_compute improves compile-time somewhat. But I can still confirm variable tracking : 0.39 ( 1%) usr 0.00 ( 0%) sys 0.41 ( 1%) wall5504 kB ( 6%) ggc var-tracking dataflow : 34.96 (84%) usr 0.16 (53%) sys 35.10 (84%) wall 47 kB ( 0%) ggc as general observation I wonder why the dataflow problem computes the _union_ as opposed to the intersection of the info on the preds in the !MAY_HAVE_DEBUG_INSNS case. Also if the MAY_HAVE_DEBUG_INSNS case really computes an intersection (as documented) then it can avoid repeated clearing of the in set and only needs to dataflow_set_merge from changed edges. Now the discrepancy in wrt the !MAY_HAVE_DEBUG_INSNS case makes me not trust that comment blindly ... I think it isn't about MAY_HAVE_DEBUG_INSNS or not, but the union vs. intersection depends on if the var is tracked by VALUEs or not, i.e. onepart decls vs. others. From a quick look var-tracking doesn't seem to take the opportunity of pruning its sets based on variable scopes (it would need to compute scope liveness in vt_initialize). That has been discussed and refused by GDB folks AFAIK. E.g. see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00960.html (though I think it was mostly IRC based later on). Anyway, here's a patch improving compile-time for this testcase by ~6% Index: gcc/var-tracking.c === --- gcc/var-tracking.c (revision 206599) +++ gcc/var-tracking.c (working copy) @@ -6934,12 +6934,12 @@ vt_find_locations (void) bool success = true; timevar_push (TV_VAR_TRACKING_DATAFLOW); - /* Compute reverse completion order of depth first search of the CFG + /* Compute reverse top sord order of the inverted CFG so that the data-flow runs faster. */ - rc_order = XNEWVEC (int, n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS); + rc_order = XNEWVEC (int, n_basic_blocks_for_fn (cfun)); bb_order = XNEWVEC (int, last_basic_block_for_fn (cfun)); - pre_and_rev_post_order_compute (NULL, rc_order, false); - for (i = 0; i n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS; i++) + int num = inverted_post_order_compute (rc_order); + for (i = 0; i num; i++) bb_order[rc_order[i]] = i; free (rc_order); If it doesn't regress on other testcases (var-tracking speed wise), then that LGTM.
[Bug tree-optimization/59860] [4.8/4.9 Regression] ICE in compute_may_aliases, at tree-ssa-structalias.c:6843
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59860 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jan 20 11:01:53 2014 New Revision: 206799 URL: http://gcc.gnu.org/viewcvs?rev=206799root=gccview=rev Log: 2014-01-20 Richard Biener rguent...@suse.de PR middle-end/59860 * builtins.c (fold_builtin_strcat): Remove case better handled by tree-ssa-strlen.c. * gcc.dg/pr59860.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr59860.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/59860] [4.8/4.9 Regression] ICE in compute_may_aliases, at tree-ssa-structalias.c:6843
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59860 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Jan 20 11:06:21 2014 New Revision: 206800 URL: http://gcc.gnu.org/viewcvs?rev=206800root=gccview=rev Log: 2014-01-20 Richard Biener rguent...@suse.de PR middle-end/59860 * builtins.c (fold_builtin_strcat): Remove case better handled by tree-ssa-strlen.c. * gcc.dg/pr59860.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/pr59860.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/builtins.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/59860] [4.8/4.9 Regression] ICE in compute_may_aliases, at tree-ssa-structalias.c:6843
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59860 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug libstdc++/59829] Calling vector::data() occurs undefined behavior when the vector is empty
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59829 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-20 Component|c++ |libstdc++ Ever confirmed|0 |1
[Bug bootstrap/59496] [4.9 Regression] Bootstrap fails on powerpc-apple-darwin9 after r205685
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59496 --- Comment #7 from Iain Sandoe iains at gcc dot gnu.org --- Author: iains Date: Mon Jan 20 11:20:24 2014 New Revision: 206802 URL: http://gcc.gnu.org/viewcvs?rev=206802root=gccview=rev Log: gcc: PR bootstrap/59496 * config/rs6000/darwin.h (ADJUST_FIELD_ALIGN): Fix unused variable warning. Amend comment to reflect current functionality. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/darwin.h
[Bug c++/59886] New: ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 Bug ID: 59886 Summary: ICE in expand_expr_real_2 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: larsbj at gullik dot net Created attachment 31897 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31897action=edit Reduced preprocessed code. g++ --version g++ (GCC) 4.9.0 20140120 (experimental) as of rev 206794 When compiling the attached preprocessed code (somewhat reduced), I get the following ICE: g++ -std=gnu++11 DnsLocatorProfiles.ii functional/protocols/dnslocator/DnsLocatorProfiles.cpp: In function ‘void __static_initialization_and_destruction_0(int, int)’: functional/protocols/dnslocator/DnsLocatorProfiles.cpp:58:5: internal compiler error: in expand_expr_real_2, at expr.c:9201 }; ^ 0x77c193 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/gcc/expr.c:9201 0x6c122c expand_gimple_stmt_1 ../../gcc/gcc/cfgexpand.c:3249 0x6c122c expand_gimple_stmt ../../gcc/gcc/cfgexpand.c:3309 0x6c18cb expand_gimple_basic_block ../../gcc/gcc/cfgexpand.c:5149 0x6c3dc6 gimple_expand_cfg ../../gcc/gcc/cfgexpand.c:5715 0x6c3dc6 execute ../../gcc/gcc/cfgexpand.c:5935
[Bug c++/59886] ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 Lars Gullik Bjønnes larsbj at gullik dot net changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de, ||jakub at gcc dot gnu.org --- Comment #1 from Lars Gullik Bjønnes larsbj at gullik dot net --- Add likely suspects to Cc.
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org --- Created attachment 31898 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31898action=edit pr59396.diff: Tentative patch for avr.c PR target/59396 * config/avr/avr.c (avr_set_current_function): If the first char of the function name is skipped, make sure it is actually '*'.
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org --- http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00529.html Issue will occur since r200901 (trunk), r200902 (4.8.2) , r200903 (4.7.4).
[Bug sanitizer/56454] need to rename attribute no_address_safety_analysis to no_sanitize_address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454 Yury Gribov y.gribov at samsung dot com changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #15 from Yury Gribov y.gribov at samsung dot com --- Kostya, can you close?
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 Martin Nowak code at dawg dot eu changed: What|Removed |Added CC||code at dawg dot eu --- Comment #3 from Martin Nowak code at dawg dot eu --- Is there a simple workaround until this is fixed?
[Bug sanitizer/56454] need to rename attribute no_address_safety_analysis to no_sanitize_address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56454 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Kostya Serebryany kcc at gcc dot gnu.org --- (In reply to Yury Gribov from comment #15) Kostya, can you close? Indeed.
[Bug debug/31412] var-tracking.c is slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412 --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org --- Seems to be gone on trunk (4.9) variable tracking : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 48 kB ( 0%) ggc var-tracking dataflow : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 4 kB ( 0%) ggc var-tracking emit : 0.02 ( 1%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc 4.8 still has variable tracking : 1.29 (35%) usr 0.01 ( 6%) sys 1.30 (33%) wall 2556 kB ( 4%) ggc not sure what fixed it.
[Bug c/59887] New: 4.6 regression (4.6.3-14+rpi1 - 4.4.7-3+rpi1) internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59887 Bug ID: 59887 Summary: 4.6 regression (4.6.3-14+rpi1 - 4.4.7-3+rpi1) internal compiler error: Segmentation fault Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: steven.valsesia at gmail dot com Hi ! When i try to build THE hello world !\n on my raspberry (raspbian), i get an internal compiler error: Segmentation fault : pi@raspberry ~/prog/test $ gcc -save-temps -o test test.c In file included from test.c:1:0: /usr/include/stdio.h:1:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.6/README.Bugs for instructions. It works if i use gcc-4.4. 4.6.3-14+rpi1 - don't works. 4.4.7-3+rpi1 - works. Here is the test.i : # 1 test.c # 1 built-in # 1 command-line # 1 test.c # 1 /usr/include/stdio.h 1 3 4 My Linux : Linux raspberry 3.6.11+ #538 PREEMPT Fri Aug 30 20:42:08 BST 2013 armv6l GNU/Linux It's my first bug-report, I hope i'm doing it rigth !
[Bug target/59888] New: ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 Bug ID: 59888 Summary: ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE ... Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, janus at gcc dot gnu.org Host: x86_64-apple-darwin1(2|3) Target: x86_64-apple-darwin1(2|3) Build: x86_64-apple-darwin1(2|3) For the code at http://gcc.gnu.org/ml/fortran/2014-01/msg00080.html and the modified one below module F03_ISO_C use, intrinsic :: iso_c_binding contains integer(c_int) function compute() bind(c) result(compute) use, intrinsic :: iso_c_binding implicit none compute = 1 return end function compute integer function F03_ISO_C_init() ! use F03_ISO_C use, intrinsic :: iso_c_binding implicit none call USE_FUNC_PTR(c_funloc(compute)) F03_ISO_C_init = 1 return end function F03_ISO_C_init subroutine USE_FUNC_PTR(f1) use, intrinsic :: iso_c_binding implicit none type(c_funptr) :: f1 print *, f1, is the address end subroutine USE_FUNC_PTR end module F03_ISO_C use F03_ISO_C use, intrinsic :: iso_c_binding implicit none integer :: i i = F03_ISO_C_init() print *, i end the darwin1(2|3) linker emits the warning ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in anon from /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//ccA26PZ2.o. To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie while the output for the above test is 4294970677 is the address 1 Compiling the tests with -Wl,-no_pie silences the warning as advertised without changing the output.
[Bug target/59888] ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-20 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- CAVEAT: don't try to use print *, F03_ISO_C_init() or you are likely to be hit by pr30617 (no recursive I/O with the same unit).
[Bug other/59889] New: gcj: internal compiler error: Killed: 9 (program jc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59889 Bug ID: 59889 Summary: gcj: internal compiler error: Killed: 9 (program jc1) Product: gcc Version: 4.6.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: stefanao at gmail dot com Trying to build the port net-p2p/deluge in a FreeBSD 9.2-Release AMD64 jail results in an gcj: internal compiler error: Killed: 9 (program jc1) Steps taken: - create directories for jail - fetch ftp://ftp.freebsd.org/pub/FreeBSD/releases/`uname -m`/`uname -m`/`uname -r | cut -d- -f1-2`/base.txz - extract and start jail - pkg_add -r portmaster - portmaster -H net-p2p/deluge This generated the attached output. This is my first bug report, please be kind and tell me what other info you might need.
[Bug middle-end/59448] Code generation doesn't respect C11 address-dependency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com --- Thanks for the testcase. At this point I think we need Andrew MacLeod or Torvald Riegel to review it and assess what should happen where to fix this (both for direct uses of the atomic built-in functions, and for _Atomic / std::atomic). Since the original bug report it has come to my attention that there are known ambiguities in how the C11/C++11 memory model is mapped to processor operations on some architectures, which will need to be addressed in platform ABIs for interoperation between implementations (when one thread is built with one implementation and the other thread with another implementation, for example). http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html (It is not clear to me if research in this area is sufficiently advanced to provide a good way for ABIs to specify this that is unambiguous and does not inhibit optimizations within a single implementation.) It will also of course be necessary for ABIs to specify such things as alignment for C11 _Atomic for that to interoperate between implementations (for GCC at present, if the size of the type is 8 / 16 / 32 / 64/ 128 bits, the alignment gets increased to match that of the corresponding core type). But first it may take a while for things to work reliably within single implementations.
[Bug other/59889] gcj: internal compiler error: Killed: 9 (program jc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59889 --- Comment #1 from Stefan stefanao at gmail dot com --- Created attachment 31899 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31899action=edit output of the portmaster -H command Unfortunately, the entire log is too long, I put it on my google drive under this link: https://drive.google.com/file/d/0B-Cx1r7LARUSejIyNGRnazBhSEU/edit?usp=sharing
[Bug c++/59886] ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- You must be building with release checking, right, otherwise I don't see how this could have made all the way till expansion. Anyway, the suspect commit is actually r206639, we have a GIMPLE_ASSIGN with RANGE_EXPR on the rhs, which is of course invalid.
[Bug c++/59886] ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 --- Comment #3 from Lars Gullik Bjønnes larsbj at gullik dot net --- Yes, the compiler is built with: ../gcc/configure --prefix=/opt/gcc/gcc-trunk --enable-checking=release --enable-languages=c,c++,lto
[Bug other/59889] gcj: internal compiler error: Killed: 9 (program jc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59889 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-20 Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- 'Killed' means sth killed gcc, likely you simply need more memory (also check ulimits).
[Bug c/59887] 4.6 regression (4.6.3-14+rpi1 - 4.4.7-3+rpi1) internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59887 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Seems to be a completely non-functional toolchain. Report a bug to where you got it from.
[Bug other/59889] gcj: internal compiler error: Killed: 9 (program jc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59889 --- Comment #3 from Stefan stefanao at gmail dot com --- (In reply to Richard Biener from comment #2) 'Killed' means sth killed gcc, likely you simply need more memory (also check ulimits). ulimit: unlimited RAM installed: 1GB - too little? (log file here, first link broken: https://drive.google.com/file/d/0B-Cx1r7LARUSWHJBMnJNQ3VucWM/edit?usp=sharing)
[Bug c++/59886] ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-20 Ever confirmed|0 |1 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Thus confirmed.
[Bug other/59889] gcj: internal compiler error: Killed: 9 (program jc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59889 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Stefan from comment #3) (In reply to Richard Biener from comment #2) 'Killed' means sth killed gcc, likely you simply need more memory (also check ulimits). ulimit: unlimited RAM installed: 1GB - too little? Yes, very likely. You can try dropping -g if you use it or lower the optimization level. (log file here, first link broken: https://drive.google.com/file/d/0B-Cx1r7LARUSWHJBMnJNQ3VucWM/ edit?usp=sharing)
[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878 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 --- But the prerequisites.html already says Use --with-isl=system. So to me it looks like a pilot error.
[Bug c++/59865] gnu multiversion calculates wrong target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59865
--- Comment #2 from mib.bugzilla at gmail dot com ---
Thanks. I realized after I posted that the test case isn't definitive. Improved
test case pasted below.
Inspection of the assembly listing shows that popcnt is being checked before
arch=corei7. I was testing to see the precendence of arch= versus isa by
creating foo for all isa, then seeing where a single arch= is sorted in the
dispatch function.
cat core-pop.C
#include assert.h
#include string.h
#include cstdio
const char * __attribute__ ((target(default))) foo(void)
{ return(default wins\n);}
const char* __attribute__ ((target(arch=corei7))) foo(void)
{ return(corei7 wins\n);}
const char* __attribute__ ((target(popcnt))) foo(void)
{ return(popcnt wins\n);}
int main ()
{
const char *result = foo ();
if (__builtin_cpu_is (corei7)) puts(builtin cpu is corei7\n);
if (__builtin_cpu_is (corei7))
assert ( 0 == strcmp(result, corei7 wins));
return 0;
}
-bash-4.1$ g++ core-pop.C -S
-bash-4.1$ g++ core-pop.C
-bash-4.1$ grep movl core-pop.s | grep foov //From dispatch function
movl$_Z3foov.popcnt, %eax
movl$_Z3foov.arch_corei7, %eax
movl$_Z3foov, %eax
-bash-4.1$ ./a.out
builtin cpu is corei7
a.out: core-pop.C:15: int main(): Assertion `0 == strcmp(result, corei7
wins)' failed.
Aborted (core dumped)
[Bug bootstrap/59878] [4.9 Regression] ISL from cloog does not work with trunk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59878 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Use --with-isl=system to direct CLooG to pick up an already installed ISL, otherwise it will use ISL 0.11.1 as bundled with CLooG doesn't exactly suggest that using the ISL 0.11.1 bundled with CLooG will not work though (it's exactly the version suggested ...) So the wording could be improved.
[Bug rtl-optimization/59890] New: var-tracking.c:val_reset segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59890 Bug ID: 59890 Summary: var-tracking.c:val_reset segfaults Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org With changed iteration order during bootstrap I get into #0 0x00c99933 in pointer_set_lookup (pset=0x0, p=0x21d3f20, ix= 0x7fffd9c8) at /space/rguenther/src/svn/trunk/gcc/pointer-set.c:86 #1 0x00c99aa7 in pointer_map_contains (pmap=0x0, p=0x21d3f20) at /space/rguenther/src/svn/trunk/gcc/pointer-set.c:211 #2 0x0105906e in val_reset (set=0x2109338, dv=0x21d3f20) at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:2511 #3 0x010599dd in variable_post_merge_new_vals (slot=0x21e8fa0, dfpm= 0x7fffdb80) at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:4429 #4 0x01061ab2 in hash_tablevariable_hasher, xcallocator::traverse_noresizedfset_post_merge*, (variable_post_merge_new_vals(variable_def**, dfset_post_merge*)) (this=0x7fffdb90, argument=0x7fffdb80) at /space/rguenther/src/svn/trunk/gcc/hash-table.h:928 #5 0x01061b39 in hash_tablevariable_hasher, xcallocator::traversedfset_post_merge*, (variable_post_merge_new_vals(variable_def**, dfset_post_merge*)) (this=0x7fffdb90, argument=0x7fffdb80) at /space/rguenther/src/svn/trunk/gcc/hash-table.h:950 #6 0x01059bdc in dataflow_post_merge_adjust (set=0x2109338, permp= 0x2109838) at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:4555 #7 0x0105d2f7 in vt_find_locations () at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:7021 where val_reset is called with a NULL local_get_addr_cache. The fix seems obvious.
[Bug rtl-optimization/59890] var-tracking.c:val_reset segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59890
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
Even with the obvious fix to val_reset
Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c (revision 206808)
+++ gcc/var-tracking.c (working copy)
@@ -2501,7 +2501,8 @@ val_reset (dataflow_set *set, decl_or_va
gcc_assert (var-n_var_parts == 1);
- if (var-onepart == ONEPART_VALUE)
+ if (var-onepart == ONEPART_VALUE
+ local_get_addr_cache != NULL)
{
rtx x = dv_as_value (dv);
void **slot;
I get during -m32 multilib x86_64 libjava build
Program received signal SIGSEGV, Segmentation fault.
vt_get_canonicalize_base (loc=0x0)
at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:1985
1985 || GET_CODE (loc) == AND)
(gdb) bt
#0 vt_get_canonicalize_base (loc=0x0)
at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:1985
#1 0x00ba7db0 in local_get_addr_clear_given_value (v=optimized out,
slot=0x1ab8c28, x=0x1a6bdc8)
at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:2484
#2 0x008bfeec in pointer_map_traverse (pmap=0x0, fn=0x1ab8c28,
data=0x1a6bdc8) at /space/rguenther/src/svn/trunk/gcc/pointer-set.c:269
#3 0x00bb6612 in val_reset (set=set@entry=0x1ab74b8,
dv=dv@entry=0x1a6bdc8)
at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:2522
#4 0x00bba55c in val_resolve (set=set@entry=0x1ab74b8, val=0x1a6bdc8,
loc=0x760b6b20, insn=insn@entry=0x74c07dc8)
at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:2597
#5 0x00bbac6f in compute_bb_dataflow (
bb=error reading variable: Unhandled dwarf expression opcode 0xfa)
at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:6695
#6 0x00bbbfa9 in vt_find_locations ()
at /space/rguenther/src/svn/trunk/gcc/var-tracking.c:7047
Btw, this all is with
Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c (revision 206808)
+++ gcc/var-tracking.c (working copy)
@@ -6934,12 +6935,12 @@ vt_find_locations (void)
bool success = true;
timevar_push (TV_VAR_TRACKING_DATAFLOW);
- /* Compute reverse completion order of depth first search of the CFG
+ /* Compute reverse top sord order of the inverted CFG
so that the data-flow runs faster. */
- rc_order = XNEWVEC (int, n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS);
+ rc_order = XNEWVEC (int, n_basic_blocks_for_fn (cfun));
bb_order = XNEWVEC (int, last_basic_block_for_fn (cfun));
- pre_and_rev_post_order_compute (NULL, rc_order, false);
- for (i = 0; i n_basic_blocks_for_fn (cfun) - NUM_FIXED_BLOCKS; i++)
+ int num = inverted_post_order_compute (rc_order);
+ for (i = 0; i num; i++)
bb_order[rc_order[i]] = i;
free (rc_order);
which provides a nice speedup for some testcases (inverted post-order
is the correct order for a forward dataflow problem).
static bool
local_get_addr_clear_given_value (const void *v ATTRIBUTE_UNUSED,
void **slot, void *x)
{
if (vt_get_canonicalize_base ((rtx)*slot) == x)
*slot = NULL;
return true;
}
if you do that again you have to guard against a cleared valued!
(pointer-map does not allow removal)
Index: gcc/var-tracking.c
===
--- gcc/var-tracking.c (revision 206808)
+++ gcc/var-tracking.c (working copy)
@@ -2481,7 +2481,8 @@ static bool
local_get_addr_clear_given_value (const void *v ATTRIBUTE_UNUSED,
void **slot, void *x)
{
- if (vt_get_canonicalize_base ((rtx)*slot) == x)
+ if (*slot != NULL
+ vt_get_canonicalize_base ((rtx)*slot) == x)
*slot = NULL;
return true;
}
[Bug debug/31412] var-tracking.c is slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org --- Seems it was r204698.
[Bug other/59889] gcj: internal compiler error: Killed: 9 (program jc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59889 --- Comment #5 from Stefan stefanao at gmail dot com --- (In reply to Richard Biener from comment #4) (In reply to Stefan from comment #3) (In reply to Richard Biener from comment #2) 'Killed' means sth killed gcc, likely you simply need more memory (also check ulimits). ulimit: unlimited RAM installed: 1GB - too little? Yes, very likely. You can try dropping -g if you use it or lower the optimization level. (log file here, first link broken: https://drive.google.com/file/d/0B-Cx1r7LARUSWHJBMnJNQ3VucWM/ edit?usp=sharing) Well, thank you very much. Increasing memory to 2GB solved this issue. The following might be beyond a bug report, but I am testing this on a VM right now, my production machine has a bit less than 2GB. Could you explain to me what you meant by 'dropping -g or lowering the optimization level'? How would I do that? Thanks again!
[Bug c/59887] 4.6 regression (4.6.3-14+rpi1 - 4.4.7-3+rpi1) internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59887 --- Comment #2 from steven valsesia steven.valsesia at gmail dot com --- (In reply to Richard Biener from comment #1) Seems to be a completely non-functional toolchain. Report a bug to where you got it from. Sorry but i don't understand, why does it work with gcc-4.4 ? And not with gcc-4.6 ? Thank you !
[Bug other/59889] gcj: internal compiler error: Killed: 9 (program jc1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59889 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Not a bug then.
[Bug libstdc++/56267] [4.7/4.8/4.9 Regression] unordered containers require Assignable hash function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56267 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Mon Jan 20 15:49:39 2014 New Revision: 206834 URL: http://gcc.gnu.org/viewcvs?rev=206834root=gccview=rev Log: PR libstdc++/56267 * include/bits/hashtable_policy.h (_Hash_code_base... false): Grant friendship to _Local_iterator_base..., false. (_Local_iterator_base): Give protected access to all existing members. (_Local_iterator_base::_M_curr()): New public accessor. (_Local_iterator_base::_M_get_bucket()): New public accessor. (_Local_iterator_base..., false::_M_init()): New function to manage the lifetime of the _Hash_code_base explicitly. (_Local_iterator_base..., false::_M_destroy()): Likewise. (_Local_iterator_base..., false): Define copy constructor and copy assignment operator that use new functions to manage _Hash_code_base. (operator==(const _Local_iterator_base, const _Local_iterator_base), operator==(const _Local_iterator_base, const _Local_iterator_base)): Use public API for _Local_iterator_base. * include/debug/safe_local_iterator.h (_Safe_local_iterator): Likewise. * include/debug/unordered_map (__debug::unordered_map::erase(), __debug::unordered_multimap::erase()): Likewise. * include/debug/unordered_set (__debug::unordered_set::erase(), __debug::unordered_multiset::erase()): Likewise. * testsuite/23_containers/unordered_set/56267-2.cc: New test. Added: trunk/libstdc++-v3/testsuite/23_containers/unordered_set/56267-2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/hashtable_policy.h trunk/libstdc++-v3/include/debug/safe_local_iterator.h trunk/libstdc++-v3/include/debug/unordered_map trunk/libstdc++-v3/include/debug/unordered_set
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #4 from Georg-Johann Lay gjl at gcc dot gnu.org --- (In reply to Martin Nowak from comment #3) Is there a simple workaround until this is fixed? None that I know of, at least if you don't want to change the sources. As the patch above has not been approved, it's unlikely this will ever get fixed...
[Bug c++/59886] [4.9 Regression] ICE in expand_expr_real_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|--- |4.9.0
Summary|ICE in expand_expr_real_2 |[4.9 Regression] ICE in
||expand_expr_real_2
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase:
struct A { A (); ~A (); };
struct B { A b[4]; };
struct C { B c[5]; };
const C e = {};
[Bug c++/59886] [4.9 Regression] C++ array init optimization results in RANGE_EXPRs in assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Even the const there isn't needed. Anyway, the bug I think is that split_nonconstant_init_1 doesn't handle RANGE_EXPR field_index in the if (TREE_CODE (value) == CONSTRUCTOR) case (it handles it in the else if (!initializer_constant_valid_p (value, inner_type)) case).
[Bug c++/59868] Extremely slow compile times with -g (var-tracking)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59868 --- Comment #6 from Michael Sartain mikesart at gmail dot com --- Added -fno-var-tracking and build time dropped to 1:30. Is this something that I should revisit when gcc 4.9 is released? Thanks much for the help.
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #5 from Martin Nowak code at dawg dot eu --- (In reply to Georg-Johann Lay from comment #4) As the patch above has not been approved, it's unlikely this will ever get fixed... This should have a high priority, it makes LTO completely unusable on AVR.
[Bug c++/59886] [4.9 Regression] C++ array init optimization results in RANGE_EXPRs in assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59886 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 31900 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31900action=edit gcc49-pr59886.patch Untested partial patch. I believe we want to increment the num_split_elts for all the elements in the range, not just the first one. And I think we need a loop around the inner split_nonconstant_init_1 emitted code, e.g. as done in the attached patch (completely untested). What the patch doesn't handle and probably has to is a cleanup for it though, which if the construction throws in the second or later iteration will just destruct everything the earlier iterations constructed, right? I think the current iteration will be already properly destructed (or not constructed at all). Jason, can you please have a look and take this over?
[Bug other/58996] [4.9 regression] build failure in libcilkrts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58996 --- Comment #18 from bviyer at gcc dot gnu.org --- Author: bviyer Date: Mon Jan 20 17:49:22 2014 New Revision: 206846 URL: http://gcc.gnu.org/viewcvs?rev=206846root=gccview=rev Log: Fix for PR other/58996. +2014-01-20 Balaji V. Iyer balaji.v.i...@intel.com + + PR other/58996 + * configure.ac: Added a check for pthread affinity support. + * runtime/os-unix.c: Likewise. + * configure: Regenerate. + Modified: trunk/libcilkrts/ChangeLog trunk/libcilkrts/configure trunk/libcilkrts/configure.ac trunk/libcilkrts/runtime/os-unix.c
[Bug tree-optimization/59891] New: ICE on invalid code (with div-by-zero) at all optimization levels on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891
Bug ID: 59891
Summary: ICE on invalid code (with div-by-zero) at all
optimization levels on x86_64-linux-gnu
Product: gcc
Version: 4.9.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 with the current gcc trunk and
4.8 at all the optimization levels on x86_64-linux-gnu in both 32-bit and
64-bit modes.
The code causes gcc 4.7 to hang at all optimization levels.
It is a regression from 4.6.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/4.9.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 4.9.0 20140120 (experimental) [trunk revision 206798] (GCC)
$
$ gcc-trunk -O0 small.c
small.c: In function ‘main’:
small.c:6:28: warning: division by zero [-Wdiv-by-zero]
return (0 ? a : 0) ? : 0 % 0;
^
small.c:6:3: internal compiler error: in gimplify_expr, at gimplify.c:8157
return (0 ? a : 0) ? : 0 % 0;
^
0x806fb8 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-trunk/gcc/gimplify.c:8157
0x80a139 gimplify_modify_expr
../../gcc-trunk/gcc/gimplify.c:4493
0x80a139 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-trunk/gcc/gimplify.c:7441
0x80ec18 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-trunk/gcc/gimplify.c:5334
0x810802 gimplify_and_add(tree_node*, gimple_statement_base**)
../../gcc-trunk/gcc/gimplify.c:384
0x811da0 gimplify_return_expr
../../gcc-trunk/gcc/gimplify.c:1234
0x808557 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-trunk/gcc/gimplify.c:7688
0x80ec18 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-trunk/gcc/gimplify.c:5334
0x80fe13 gimplify_bind_expr
../../gcc-trunk/gcc/gimplify.c:1072
0x8082d0 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc-trunk/gcc/gimplify.c:7638
0x80ec18 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc-trunk/gcc/gimplify.c:5334
0x80ed6a gimplify_body(tree_node*, bool)
../../gcc-trunk/gcc/gimplify.c:8548
0x80f3b1 gimplify_function_tree(tree_node*)
../../gcc-trunk/gcc/gimplify.c:8701
0x69ec97 analyze_function
../../gcc-trunk/gcc/cgraphunit.c:649
0x6a0724 analyze_functions
../../gcc-trunk/gcc/cgraphunit.c:1017
0x6a1660 finalize_compilation_unit()
../../gcc-trunk/gcc/cgraphunit.c:2310
0x55b802 c_write_global_declarations()
../../gcc-trunk/gcc/c/c-decl.c:10401
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.
$
-
unsigned int a;
int
main ()
{
return (0 ? a : 0) ? : 0 % 0;
}
[Bug tree-optimization/59891] [4.7/4.8/4.9 Regression] ICE on invalid code (with div-by-zero) at all optimization levels on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59891 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-01-20 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.7.4 Summary|ICE on invalid code (with |[4.7/4.8/4.9 Regression] |div-by-zero) at all |ICE on invalid code (with |optimization levels on |div-by-zero) at all |x86_64-linux-gnu|optimization levels on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug tree-optimization/59860] [4.8/4.9 Regression] ICE in compute_may_aliases, at tree-ssa-structalias.c:6843
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59860 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jan 20 18:18:21 2014 New Revision: 206848 URL: http://gcc.gnu.org/viewcvs?rev=206848root=gccview=rev Log: PR middle-end/59860 * tree.h (fold_builtin_strcat): New prototype. * builtins.c (fold_builtin_strcat): No longer static. Add len argument, if non-NULL, don't call c_strlen. Optimize directly into __builtin_memcpy instead of __builtin_strcpy. (fold_builtin_2): Adjust fold_builtin_strcat caller. * gimple-fold.c (gimple_fold_builtin): Handle BUILT_IN_STRCAT. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/gimple-fold.c trunk/gcc/tree.h
[Bug debug/31412] var-tracking.c is slow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31412 --- Comment #22 from Kenneth Zadeck zadeck at naturalbridge dot com --- if i had to put money on it, i would say that it is not dead, it is only sleeping. kenny
[Bug tree-optimization/59860] [4.8/4.9 Regression] ICE in compute_may_aliases, at tree-ssa-structalias.c:6843
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59860 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Mon Jan 20 18:19:54 2014 New Revision: 206849 URL: http://gcc.gnu.org/viewcvs?rev=206849root=gccview=rev Log: PR middle-end/59860 * tree.h (fold_builtin_strcat): New prototype. * builtins.c (fold_builtin_strcat): No longer static. Add len argument, if non-NULL, don't call c_strlen. Optimize directly into __builtin_memcpy instead of __builtin_strcpy. (fold_builtin_2): Adjust fold_builtin_strcat caller. * gimple-fold.c (gimple_fold_builtin): Handle BUILT_IN_STRCAT. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/builtins.c branches/gcc-4_8-branch/gcc/gimple-fold.c branches/gcc-4_8-branch/gcc/tree.h
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org --- Thanks, Daniel. I'm still trying to understand what's happening here so I can reproduce it. libintl_textdomain is the GNU gettext implementation of the textdomain(3) function. On my Fedora systems textdomain(3) is provided by glibc, not GNU gettext, so it defines the symbol textdomain not libintl_textdomain. The GNU clocale model unconditionally includes libintl.h in bits/messages_members.h and uses textdomain, and assumes it comes from glibc: # Don't call AM-GNU-GETTEXT here. Instead, assume glibc. AC_CHECK_PROG(check_msgfmt, msgfmt, yes, no) if test x$check_msgfmt = xyes test x$enable_nls = xyes; then USE_NLS=yes fi When using --disable-nls the configure script does not check whether -lintl is needed for gettext: # A standalone libintl (e.g., GNU libintl) may be in use. if test $USE_NLS = yes; then AC_CHECK_HEADERS([libintl.h], [], USE_NLS=no) AC_SEARCH_LIBS(gettext, intl, [], USE_NLS=no) fi So I need to know which GNU/Linux distro you are using, and why it does not provide textdomain in glibc. 1) Which GNU/Linux distro are you using? 2) Does your libintl.h come from glibc or gettext? 3) What does this command print? g++ -E -x c++ - '#include libintl.h' | head 4) What does this command print? which msgfmt Here's an untested patch that might help: diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4 index fcdcd9a..50b0b0e 100644 --- a/libstdc++-v3/acinclude.m4 +++ b/libstdc++-v3/acinclude.m4 @@ -2093,6 +2093,7 @@ AC_DEFUN([GLIBCXX_ENABLE_CLOCALE], [ AC_CHECK_PROG(check_msgfmt, msgfmt, yes, no) if test x$check_msgfmt = xyes test x$enable_nls = xyes; then USE_NLS=yes +AC_SEARCH_LIBS(gettext, intl, [], USE_NLS=no) fi # Export the build objects. for ling in $ALL_LINGUAS; do \
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org --- A possible workaround is to ensure that *either* glibc provides textdomain(3) *or* you have GNU gettext installed and do not use --disable-nls
[Bug tree-optimization/59892] New: out of bounds array access is misoptimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59892
Bug ID: 59892
Summary: out of bounds array access is misoptimized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: alexei.starovoitov at gmail dot com
Created attachment 31901
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31901action=edit
test case
attached test case was narrowed down from linux kernel
file drivers/scsi/isci/host.h
#define for_each_isci_host(id, ihost, pdev) \
for (id = 0, ihost = to_pci_info(pdev)-hosts[id]; \
id ARRAY_SIZE(to_pci_info(pdev)-hosts) ihost; \
ihost = to_pci_info(pdev)-hosts[++id])
'hosts' array has fixed size of 2:
struct isci_pci_info {
struct msix_entry msix_entries[SCI_MAX_MSIX_INT];
struct isci_host *hosts[SCI_MAX_CONTROLLERS];
struct isci_orom *orom;
};
and loop is accessing 3rd element of the array.
Behavior is undefined, but gcc 4.7 and older were ok,
whereas GCC 4.8 and the latest 4.9 are misoptimizing the code
by dropping 'id 2' loop condition.
$ gcc -O0 array_out_of_bounds.c
$ ./a.out
(0 2) == 1
(1 2) == 1
$ gcc -O2 array_out_of_bounds.c
$ ./a.out
(0 2) == 1
(1 2) == 1
Segmentation fault (core dumped)
'cunrolli' pass is confused with such loop condition and produces wrong tree:
bb 3:
_19 = (int) _16;
printf ((%d %d) == %d\n, 0, 2, _19);
i_21 = 1;
isci_host_22 = v.hosts[i_21];
_6 = i_21 = 1;
_7 = isci_host_22 != 0B;
_8 = _6 _7;
if (_8 != 0)
goto bb 4;
else
goto bb 5;
bb 4:
_9 = (int) _6;
printf ((%d %d) == %d\n, i_21, 2, _9);
i_11 = i_21 + 1;
__builtin_unreachable ();
if 'cunrolli' is disabled, the VRP pass is equally confused:
bb 3:
_9 = 1;
printf ((%d %d) == %d\n, i_1, 2, 1);
i_11 = i_1 + 1;
isci_host_12 = v.hosts[i_11];
bb 4:
# i_1 = PHI 0(2), i_11(3)
# isci_host_2 = PHI isci_host_5(2), isci_host_12(3)
_6 = 1;
_7 = isci_host_2 != 0B;
_8 = _7;
if (_8 != 0)
goto bb 3;
else
goto bb 5;
bb 5:
return 0;
and optimizes i=1 condition into _6 = 1 above, whereas bb4 can
be executed for i=2
worst is that compiler doesn't warn on the problem.
-Wall and -Warray-bounds don't see it.
Though the code is erroneous by C standard definition, GCC should be smarter
and prevent misoptimization where it can. As a minimum it should warn about
such cases.
[Bug c++/58116] missed-optimization: const temporaries could be promoted to static
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58116 --- Comment #4 from Andy Lutomirski luto at mit dot edu --- Sorry -- I forgot about the recursive / threaded case. (I keep meaning to propose something like [[non_unique_address]] to enable optimizations like this and things zero-byte struct members.)
[Bug tree-optimization/59892] out of bounds array access is misoptimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59892 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- The warning should be there already.
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #6 from pieter.agten at gmail dot com --- (In reply to Martin Nowak from comment #5) (In reply to Georg-Johann Lay from comment #4) As the patch above has not been approved, it's unlikely this will ever get fixed... This should have a high priority, it makes LTO completely unusable on AVR. Isn't it just a warning?
[Bug tree-optimization/59892] out of bounds array access is misoptimized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59892
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||trippels at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
struct isci_host;
struct isci_orom;
struct isci_pci_info {
struct isci_host *hosts[2];
struct isci_orom *orom;
} v = {{(struct isci_host *)1,(struct isci_host *)1}, 0};
int printf(const char *fmt, ...);
int isci_pci_probe()
{
int i;
struct isci_host *isci_host;
for (i = 0, isci_host = v.hosts[i];
i 2 isci_host;
isci_host = v.hosts[++i]) {
printf((%d %d) == %d\n, i, 2, (i 2));
}
return 0;
}
int main()
{
isci_pci_probe();
}
When v.hosts[0] or v.hosts[1] is NULL the loop is fine, so there is
no reason for a warning.
The testcase is obviously invalid.
[Bug libstdc++/56267] [4.7/4.8/4.9 Regression] unordered containers require Assignable hash function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56267 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.7.4 |4.9.0 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.9.0, I don't think it's worth backporting to earlier releases
[Bug rtl-optimization/59890] var-tracking.c:val_reset segfaults
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59890 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-20 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug target/59396] [avr] Wrong warning with ISR() and -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396 --- Comment #7 from Ian Thompson ijt5 at cornell dot edu --- (In reply to Martin Nowak from comment #5) This should have a high priority, it makes LTO completely unusable on AVR. I've been building with LTO for AVR without issue. The warning is purely cosmetic. If you're worried about not being able to build with -Werror (since this can't be suppressed), you could split your compile and link steps into separate commands: $ avr-gcc -Wall -Werror -mmcu=atmega8 -flto -c isr.c -o isr.o $ avr-gcc -mmcu=atmega8 -flto isr.o -o isr In function '__vector_14': isr.c:10:1: warning: '_vector_14' appears to be a misspelled signal handler [enabled by default] ISR (ADC_vect) ^ You could even do something fancy by piping the linker output to sed/grep/awk to filter out the bogus warning. Not sure if this is relevant, but the warning only comes up during linking, while any actually misspelled handlers will come up during compile. To show this even better, misspell ADC_vect in the initial example. You actually get the warning twice: isr.c: In function 'AD_vect': isr.c:10:6: warning: 'AD_vect' appears to be a misspelled signal handler [enabled by default] ISR (AD_vect) ^ isr.c:5:10: note: in definition of macro 'ISR' void vector (void) ^ In function 'AD_vect': isr.c:10:1: warning: 'D_vect' appears to be a misspelled signal handler [enabled by default] ISR (AD_vect) ^
[Bug target/59685] ICE: in output_2305, at config/i386/sse.md:8919 with -march=bdver1 -mavx512f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59685 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-01-20 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- Just missing V16SF mode in *andnotmode3mask_name. Patch in testing: --cut here-- Index: sse.md === --- sse.md (revision 206844) +++ sse.md (working copy) @@ -8906,6 +8906,8 @@ tmp = pandn; break; + case MODE_V16SF: + gcc_assert (TARGET_AVX512F); case MODE_V8SF: gcc_assert (TARGET_AVX); case MODE_V4SF: --cut here--
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 --- Comment #14 from Dâniel Fraga fragabr at gmail dot com --- (In reply to Jonathan Wakely from comment #12) So I need to know which GNU/Linux distro you are using, and why it does not provide textdomain in glibc. Hi Jonathan: 1) I'm using a customized installation, more like Linux from scratch (remember that everything worked fine before gcc 4.8.0) 2) Regarding libintl.h, I have from both glibc and gettext: /usr/include/libintl.h (glibc) /usr/local/include/libintl.h (gettext) 3) g++ -E -x c++ - '#include libintl.h' | head # 1 stdin # 1 command-line # 1 /usr/include/stdc-predef.h 1 3 4 # 1 command-line 2 # 1 stdin # 1 /usr/local/include/libintl.h 1 3 # 20 /usr/local/include/libintl.h 3 # 1 /usr/include/locale.h 1 3 4 # 25 /usr/include/locale.h 3 4 # 1 /usr/include/features.h 1 3 4 4) which msgfmt /usr/local/bin/msgfmt 5) I tested the patch and it didn't work. Same problem: /usr/local/lib64/libstdc++.so: undefined reference to `libintl_gettext' /usr/local/lib64/libstdc++.so: undefined reference to `libintl_textdomain' /usr/local/lib64/libstdc++.so: undefined reference to `libintl_bindtextdomain' collect2: error: ld returned 1 exit status *** Any other hints? Just ask and I'll test anything you want. Thanks.
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #15 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Dâniel Fraga from comment #14) 1) I'm using a customized installation, more like Linux from scratch (remember that everything worked fine before gcc 4.8.0) I don't understand how it worked previously, I think it should always have failed! 2) Regarding libintl.h, I have from both glibc and gettext: /usr/include/libintl.h (glibc) /usr/local/include/libintl.h (gettext) Thanks for the quick response, that explains the problem. G++ finds the version in /usr/local/include first, so the library gets a dependency on libintl_textdomain, but the configure checks find textdomain in glibc, so thinks there is no need to link to libintl. Any other hints? Just ask and I'll test anything you want. Thanks. If you remove /usr/local/include/libintl.h it should work, but that's not a clean solution.
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779
--- Comment #16 from Marc Glisse glisse at gcc dot gnu.org ---
AC_SEARCH_LIBS(gettext, intl, [], USE_NLS=no)
seems a bit crude, as it results in this link test:
#ifdef __cplusplus
extern C
#endif
char gettext ();
int
main ()
{
return gettext ();
;
return 0;
}
when here we would need something closer to:
#include libintl.h
int main (int argc, char**argv)
{
gettext(argv[0]);
return 0;
}
so that if libintl.h redirects gettext to libintl_gettext the link test is for
the right symbol.
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 --- Comment #17 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Marc Glisse from comment #16) AC_SEARCH_LIBS(gettext, intl, [], USE_NLS=no) seems a bit crude, as it results in this link test: It also doesn't help solve the bug :-) Yes, I realised later that we need a custom test that ensures we use the correct lib to match whichever libintl.h is included.
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 --- Comment #18 from Dâniel Fraga fragabr at gmail dot com --- (In reply to Jonathan Wakely from comment #15) (In reply to Dâniel Fraga from comment #14) Thanks for the quick response, that explains the problem. G++ finds the version in /usr/local/include first, so the library gets a dependency on libintl_textdomain, but the configure checks find textdomain in glibc, so thinks there is no need to link to libintl. So the solution is to change configure?
[Bug target/59888] ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- When I opened this PR I missed the -fshared. With it I get the linker error. On IRC Iain Sandoe gives the following workaround: (1) gfc -S F03_iso.f90 (2) apply the following patch: --- F03_iso.s2014-01-20 20:54:05.0 +0100 +++ F03_iso_orig.s2014-01-20 20:53:06.0 +0100 @@ -54,7 +54,7 @@ LCFI4: LCFI5: ret LFE1: -.const +.const_data .align 3 LC2: .quad_compute (3) gfc -shared F03_iso.s -o F03_iso.dylib (4) gfc F03_iso_main.f90 F03_iso.dylib with F03_iso_main.f90 being use F03_ISO_C use, intrinsic :: iso_c_binding implicit none integer :: F03_ISO_C_init integer :: i i = F03_ISO_C_init() print *, i end Then the executable outputs 4493950477 is the address 1 and otool -Lv gives F03_iso.dylib (compatibility version 0.0.0, current version 0.0.0) time stamp 2 Thu Jan 1 01:00:02 1970 /opt/gcc/gcc4.9w/lib/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0) time stamp 2 Thu Jan 1 01:00:02 1970 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) time stamp 2 Thu Jan 1 01:00:02 1970 /opt/gcc/gcc4.9w/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) time stamp 2 Thu Jan 1 01:00:02 1970 /opt/gcc/gcc4.9w/lib/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0) time stamp 2 Thu Jan 1 01:00:02 1970
[Bug libstdc++/56779] [4.8/4.9 Regression] libstdc++.so: undefined reference to `libintl_textdomain'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56779 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org --- Yes. Currently configure has a broken check for libintl that gives the wrong result if you have GNU gettext installed as well as glibc, and we only do that check when USE_NLS=yes. For GNU/Linux we always need textdomain even with --disable-nls so always need the libintl check.
[Bug target/59888] ld: illegal text-relocation to '_compute' ... on darwin1(2|3).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Summary|ld: warning: PIE disabled. |ld: illegal text-relocation |Absolute addressing |to '_compute' ... on |(perhaps -mdynamic-no-pic) |darwin1(2|3). |not allowed in code signed | |PIE ... | --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Changed the summary to reflect the original post.
[Bug target/59888] ld: illegal text-relocation to '_compute' ... on darwin1(2|3).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 --- Comment #4 from Iain Sandoe iains at gcc dot gnu.org --- So, essentially, the complaint from the darwin linker is that it does not want to see a relocation in the .const section (which is part of the text segment). It might be argued that this is right/wrong - but it is at least reasonable - the relevant segment should be marked read-only .. but typical darwin relocs can be re-written lazily (as and when the symbol is required). the hack, proof-of-principle, solution above was to move the reference to the .const_data section. Whether this is a back-end fault or perhaps a constraint of darwin not present for binutils-ld I cannot tell immediately and would welcome input from the Fortran maintainers as to the decoration intended for the indirect reference produced for c_funloc (defined_function).
[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #1 from Tom Tromey tromey at gcc dot gnu.org --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01284.html
