[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #11 from dominiq at lps dot ens dot fr 2009-12-24 08:12 --- *** Bug 42480 has been marked as a duplicate of this bug. *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/42480] Wrong-code for air.f90 with -O2 -fgraphite-identity
--- Comment #1 from dominiq at lps dot ens dot fr 2009-12-24 08:12 --- *** This bug has been marked as a duplicate of 42181 *** -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42480
[Bug rtl-optimization/42294] [4.5 Regression] ICE in code_motion_path_driver for 416.gamess
--- Comment #7 from abel at gcc dot gnu dot org 2009-12-24 08:18 ---
The problem here is in the incorrect handling of the transformation history.
When an insn is transformed (i.e. substituted/speculated), this is recorded so
that the insn could be found during upward code motion. Part of the data
recorded is the uid of insn on which the transformation happened. As this
second insn could get removed while filling a parallel group, and its
bookkeeping copy could be created, we need to undo the transformation while
moving through this copy instead of original insn. To do this, we also
maintain a bitmap of insn uids that could generate the copy (INSN_ORIGINATORS),
and we also check it on the copies. The actual bug was that the bitmap should
contain all ancestor insns of a copy, not only parents, as the copy found
could originated from another copy (yes, I was stupid of not thinking about
this earlier). The alternate solution would be to make the search function
recurse on INSN_ORIGINATORS bitmap, but this one seemed clearer.
Patch by Alexander below, we would need to ask someone with access to ppc64 to
test it (as a part of combined patch fixing other sel-sched bugs) in addition
to our testing.
* sel-sched-ir.h (struct _sel_insn_data): Update comment.
* sel-sched.c (move_exprs_to_boundary): Transitively add all
originators' originators.
---
gcc/sel-sched-ir.h |3 ++-
gcc/sel-sched.c|9 +
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/gcc/sel-sched-ir.h b/gcc/sel-sched-ir.h
index 1950a65..67b5b62 100644
--- a/gcc/sel-sched-ir.h
+++ b/gcc/sel-sched-ir.h
@@ -715,7 +715,8 @@ struct _sel_insn_data
bitmap found_deps;
/* An INSN_UID bit is set when this is a bookkeeping insn generated from
- a parent with this uid. */
+ a parent with this uid. If a parent is a bookkeeping copy, all its
+ originators are transitively included in this set. */
bitmap originators;
/* A hashtable caching the result of insn transformations through this one.
*/
diff --git a/gcc/sel-sched.c b/gcc/sel-sched.c
index e5ebc57..9fcc633 100644
--- a/gcc/sel-sched.c
+++ b/gcc/sel-sched.c
@@ -5211,12 +5211,21 @@ move_exprs_to_boundary (bnd_t bnd, expr_t expr_vliw,
EXECUTE_IF_SET_IN_BITMAP (current_copies, 0, book_uid, bi)
{
+ unsigned uid;
+ bitmap_iterator bi;
+
/* We allocate these bitmaps lazily. */
if (! INSN_ORIGINATORS_BY_UID (book_uid))
INSN_ORIGINATORS_BY_UID (book_uid) = BITMAP_ALLOC (NULL);
bitmap_copy (INSN_ORIGINATORS_BY_UID (book_uid),
current_originators);
+
+ /* Transitively add all originators' originators. */
+ EXECUTE_IF_SET_IN_BITMAP (current_originators, 0, uid, bi)
+ if (INSN_ORIGINATORS_BY_UID (uid))
+bitmap_ior_into (INSN_ORIGINATORS_BY_UID (book_uid),
+ INSN_ORIGINATORS_BY_UID (uid));
}
return should_move;
--
abel at gcc dot gnu dot org changed:
What|Removed |Added
CC||abel at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42294
[Bug rtl-optimization/42246] ICE in init_seqno for 186.crafty with sel-sched
--- Comment #1 from abel at gcc dot gnu dot org 2009-12-24 08:32 ---
Here, we broke pipelining of outer loops when optimizing the scheduler core.
The problems analyzed by Alexander are simple though. First, when testing
whether a loop is considered for pipelining, I decided to play safe and also
check pipelining_p in addition to the flag in the aux loop data that was
designed specially for this. Naturally, when we then disabled pipelining_p for
rescheduling pipelined loops, this broke, so to fix it we just need to stop
checking for pipelining_p. The second problem is that we use the
last_added_blocks vector when adding blocks to the region, and we failed to
initialize it correctly for the case of moving preheader blocks from an inner
loop to an outer loop when we have added the vector. Also easily fixed via
correctly initializing the vector.
Again, we would ask someone with access to ppc/ppc64 to test this patch as a
part of the combined patch with fixes for all sel-sched bugs, when our testing
will be completed.
This patch also fixes PR39453.
* sel-sched-ir.c (considered_for_pipelining_p): Do not test
for pipelining_p.
(sel_add_loop_preheaders): Add preheader to last_added_blocks.
---
gcc/sel-sched-ir.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gcc/sel-sched-ir.c b/gcc/sel-sched-ir.c
index 2469822..3c2989a 100644
--- a/gcc/sel-sched-ir.c
+++ b/gcc/sel-sched-ir.c
@@ -5825,7 +5825,7 @@ considered_for_pipelining_p (struct loop *loop)
latch. We can't use header here, because this header could be
just removed preheader and it will give us the wrong region number.
Latch can't be used because it could be in the inner loop too. */
- if (LOOP_MARKED_FOR_PIPELINING_P (loop) pipelining_p)
+ if (LOOP_MARKED_FOR_PIPELINING_P (loop))
{
int rgn = CONTAINING_RGN (loop-latch-index);
@@ -5974,7 +5974,10 @@ sel_add_loop_preheaders (void)
for (i = 0;
VEC_iterate (basic_block, preheader_blocks, i, bb);
i++)
+{
+ VEC_safe_push (basic_block, heap, last_added_blocks, bb);
sel_add_bb (bb);
+}
VEC_free (basic_block, heap, preheader_blocks);
}
--
abel at gcc dot gnu dot org changed:
What|Removed |Added
CC||abel at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42246
[Bug c/42487] FAIL: gcc.dg/debug/dwarf2/aranges-fnsec-1.c scan-assembler DW_AT_ranges
--- Comment #2 from jakub at gcc dot gnu dot org 2009-12-24 09:42 --- -gno-strict-dwarf should be added to dg-options to make darwin happy. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42487
[Bug target/42093] [4.5 regression] Compressed switch tables for Thumb2 have signed offsets
--- Comment #7 from ramana at gcc dot gnu dot org 2009-12-24 10:18 --- Matthias confirmed to me privately that his bootstrap had gone past the infinite loop in stage2 . There might be other issues with Thumb2 bootstrap - we'll open new bugs in the future for those. Updated subject line to be more appropriate. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|bootstrap |target Resolution||FIXED Summary|[4.5 regression] bootstrap |[4.5 regression] Compressed |hangs in stage2 run of |switch tables for Thumb2 |build/gengtype |have signed offsets http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42093
[Bug target/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #9 from ramana at gcc dot gnu dot org 2009-12-24 10:46 --- Subject: Bug 40887 Author: ramana Date: Thu Dec 24 10:46:00 2009 New Revision: 155453 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155453 Log: Fix PR target/40887 2009-12-24 Julian Brown jul...@codesourcery.com Ramana Radhakrishnan ramana.radhakrish...@arm.com PR target/40887 * config/arm/arm.c (output_call_mem): Remove armv5 support. * config/arm/arm.md (*call_mem): Disable for armv5. Add note. (*call_value_mem): Likewise. PR target/40887 * gcc.target/gcc.arm/pr40887.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr40887.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug rtl-optimization/42489] New: Function call never happened after compile with -foptimize-sibling-calls
In function __xmlRaiseError of error.c ( libxml2.a ) if this particular c file is compiled with optimization -O2 ( -foptimize-sibling-calls ) call to this function from xmlFatalErrMsgStrIntStr() parser.c ( libxml2.a ) will never take place, and, seems to cause dead-lock situation. Tested recompile this c file with, -fno-optimize-sibling-calls, confirm to workaround the bug. -- Summary: Function call never happened after compile with - foptimize-sibling-calls Product: gcc Version: 4.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t7 at gmail dot com GCC build triplet: x86_64-slackware-linux GCC host triplet: x86_64-slackware-linux GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug rtl-optimization/42489] Function call never happened after compile with -foptimize-sibling-calls
--- Comment #1 from t7 at gmail dot com 2009-12-24 11:44 --- Created an attachment (id=19386) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19386action=view) saves .ok compiled with -fno-optimize-sibling-calls -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug rtl-optimization/42489] Function call never happened after compile with -foptimize-sibling-calls
--- Comment #2 from t7 at gmail dot com 2009-12-24 11:57 ---
(gdb) disass $pc-30 $pc+30
Dump of assembler code from 0x4933e3 to 0x49341f:
0x004933e3 __xmlRaiseError+179: add%al,(%eax)
0x004933e5 __xmlRaiseError+181: add%al,%bh
0x004933e7 __xmlRaiseError+183: add$0x24,%al
0x004933e9 __xmlRaiseError+185: xchg %eax,%esi
0x004933ea __xmlRaiseError+186: add%al,(%eax)
0x004933ec __xmlRaiseError+188: add%cl,0x15ff0076(%ebp)
0x004933f2 __xmlRaiseError+194: movsb %ds:(%esi),%es:(%edi)
0x004933f3 __xmlRaiseError+195: inc%ecx
0x004933f4 __xmlRaiseError+196: dec%esp
0x004933f5 __xmlRaiseError+197: add%al,-0x1fba7640(%ebp)
0x004933fb __xmlRaiseError+203: je 0x4934d0 __xmlRaiseError+416
0x00493401 __xmlRaiseError+209: jmp0x493401 __xmlRaiseError+209
0x00493403 __xmlRaiseError+211: cmpl $0x0,0xc(%ebp)
0x00493407 __xmlRaiseError+215: je 0x49346f __xmlRaiseError+319
0x00493409 __xmlRaiseError+217: cmpl $0x493220,0xc(%ebp)
0x00493410 __xmlRaiseError+224: je 0x49366c __xmlRaiseError+828
0x00493416 __xmlRaiseError+230: cmpl $0x493130,0xc(%ebp)
0x0049341d __xmlRaiseError+237: je 0x49366c __xmlRaiseError+828
End of assembler dump.
(gdb) info all-registers
eax0xa07308 10515208
ecx0x77633b23 2002991907
edx0xa07303 10515203
ebx0x4f97c4 5216196
esp0x28ec10 0x28ec10
ebp0x28ec48 0x28ec48
esi0xa02ac0 10496704
edi0x1 1
eip0x493401 0x493401 __xmlRaiseError+209
eflags 0x202[ IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x53 83
gs 0x2b 43
st00(raw 0x)
st10(raw 0x)
st20(raw 0x)
st30(raw 0x)
st40(raw 0x)
st50(raw 0x)
st60(raw 0x)
st7-0 (raw 0x8000)
fctrl 0x37f895
fstat 0x4000 16384
ftag 0x 65535
fiseg 0xf800 63488
fioff 0x288ce5242520146
foseg 0xfa80 64128
fooff 0x759c060123322464
fop0x0 0
xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 repeats 16 times}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x}
xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 repeats 16 times}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x}
xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 repeats 16 times}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x}
xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 repeats 16 times}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x}
xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 repeats 16 times}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x}
xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 repeats 16 times}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x}
xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 repeats 16 times}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x}
xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0 repeats 16 times}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x}
mxcsr 0x1f80 [ IM DM ZM OM UM PM ]
mm0{uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0,
0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm1{uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0,
0x0, 0x0}, v8_int8 = {0x0, 0x0,
[Bug c++/40044] ICE when resolves overloaded functions
--- Comment #3 from dodji at seketeli dot org 2009-12-24 12:00 --- Subject: Re: ICE when resolves overloaded functions --- Comment #2 from paolo dot carlini at oracle dot com 2009-12-23 23:00 --- Dodji, is this just a duplicate of PR38600? Yes, I think so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40044
[Bug c++/40044] ICE when resolves overloaded functions
--- Comment #4 from dodji at gcc dot gnu dot org 2009-12-24 12:03 --- *** This bug has been marked as a duplicate of 38600 *** -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40044
[Bug c++/38600] Trouble mangling template_id_expr
--- Comment #11 from dodji at gcc dot gnu dot org 2009-12-24 12:03 --- *** Bug 40044 has been marked as a duplicate of this bug. *** -- dodji at gcc dot gnu dot org changed: What|Removed |Added CC||vbvan at 163 dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38600
[Bug tree-optimization/19097] [4.3/4.4/4.5 regression] Quadratic behavior with many sets for the same register in VRP
--- Comment #53 from steven at gcc dot gnu dot org 2009-12-24 13:02 --- I cannot reproduce this anymore on ia64 -- at least not for VRP and CPROP. The slowest pass is now expand: dominator optimization: 0.40 ( 1%) usr 0.00 ( 0%) sys 0.40 ( 1%) wall 2188 kB ( 3%) ggc tree CCP : 0.17 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 0 kB ( 0%) ggc tree PHI const/copy prop: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree split crit edges : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree reassociation: 0.11 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc tree PRE : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 1 kB ( 0%) ggc tree FRE : 0.12 ( 0%) usr 0.00 ( 1%) sys 0.12 ( 0%) wall 1 kB ( 0%) ggc tree code sinking : 0.08 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc tree linearize phis : 0.07 ( 0%) usr 0.00 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc tree forward propagate: 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc tree conservative DCE : 0.08 ( 0%) usr 0.01 ( 2%) sys 0.10 ( 0%) wall 0 kB ( 0%) ggc tree aggressive DCE : 0.28 ( 0%) usr 0.00 ( 1%) sys 0.28 ( 0%) wall 3 kB ( 0%) ggc tree buildin call DCE : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree DSE : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc PHI merge : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc complete unrolling: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree loop init: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree copy headers : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc tree SSA uncprop : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc tree rename SSA copies: 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree switch initialization conversion: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc dominance frontiers : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc dominance computation : 0.62 ( 1%) usr 0.00 ( 1%) sys 0.64 ( 1%) wall 0 kB ( 0%) ggc control dependences : 0.03 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc expand: 3.13 ( 5%) usr 0.06 ( 7%) sys 3.21 ( 5%) wall 17093 kB (26%) ggc forward prop : 0.79 ( 1%) usr 0.00 ( 1%) sys 0.79 ( 1%) wall 703 kB ( 1%) ggc CSE : 1.36 ( 2%) usr 0.00 ( 0%) sys 1.36 ( 2%) wall 0 kB ( 0%) ggc dead code elimination : 0.15 ( 0%) usr 0.00 ( 0%) sys 0.16 ( 0%) wall 0 kB ( 0%) ggc dead store elim1 : 0.39 ( 1%) usr 0.00 ( 0%) sys 0.39 ( 1%) wall 390 kB ( 1%) ggc loop analysis : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc CPROP : 1.96 ( 3%) usr 0.18 (23%) sys 2.15 ( 3%) wall 6094 kB ( 9%) ggc PRE : 1.26 ( 2%) usr 0.20 (27%) sys 1.46 ( 2%) wall 0 kB ( 0%) ggc auto inc dec : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 0 kB ( 0%) ggc CSE 2 : 1.69 ( 3%) usr 0.00 ( 0%) sys 1.69 ( 3%) wall 1288 kB ( 2%) ggc branch prediction : 0.22 ( 0%) usr 0.00 ( 0%) sys 0.22 ( 0%) wall 0 kB ( 0%) ggc combiner : 0.62 ( 1%) usr 0.00 ( 0%) sys 0.62 ( 1%) wall 234 kB ( 0%) ggc if-conversion : 0.05 ( 0%) usr 0.00 ( 0%) sys 0.05 ( 0%) wall 0 kB ( 0%) ggc scheduling: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc integrated RA : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 512 kB ( 1%) ggc reload: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc scheduling 2 : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 8 kB ( 0%) ggc tree if-combine : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 61.41 0.7762.18 66790 kB But this expand slowness also manifests itself at -O0 (IRA and gimplifier slow), and at -O1 and -O3 (expand). I don't find this unreasnable at all, for 2 conditionals and 2 function calls (and all the stack and temp slots saving/restoring involved). Closing. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap comparison failures
--- Comment #8 from steven at gcc dot gnu dot org 2009-12-24 13:12 --- http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01114.html fixes part of this bug, but I still get a bootstrap comparison failure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug middle-end/42484] ICE with -fopenmp
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-24 13:54 --- I think the example is valid. ifort and sunf95 accept it. -- janus at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42484
[Bug c++/41305] Infinite recursion with g++ at -O0
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-12-23 20:12:13 |2009-12-24 14:07:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41305
[Bug testsuite/38036] [4.4/4.5 Regression][AVR] FAIL: gcc.c-torture/execute/pr37573.c execution
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-12-24 14:46 --- Fixed already Rev 142978 (29th December 2008) -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38036
[Bug c++/38392] Template friend function injection
--- Comment #9 from H9XLrv5oXVNvHiUI at spambox dot us 2009-12-24 14:48 --- I know if you move the function it links (btw your link asks me for an HTTP login), but if you follow the discussion in the newsgroup it was concluded that this (the above) is actually perfectly valid standard C++ code, and anyway I think at least the error the linker gives could be more descriptive. Also the fact that other compilers fail with this code it's just because it's fairly rarely used code. For instance, Open Watcom compiled and linked the code perfectly fine without issues (and the executable was working). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/42490] New: using-directive in namespace doesn't work properly
Consider:
namespace B { struct C {}; }
namespace A { namespace C { } using namespace B; }
struct A::C c;
GCC complains:
error: 'C' in namespace 'A' does not name a type
Not knowing much about the subtleties of name lookup myself, I'm relying on the
following two sources for the code's well-formed-ness:
* Comeau 4.3.10.1 /does/ accept the code.
* The opinion of a particularly well-read regular (litb) on Freenode's C++ IRC
channel.
--
Summary: using-directive in namespace doesn't work properly
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42490
[Bug c++/38392] Template friend function injection
--- Comment #10 from paolo dot carlini at oracle dot com 2009-12-24 15:39 --- Try this one: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#329 Anyway, if you could point us to the specific sentence in the thread saying that it's legal, it would be useful. And, well, frankly I would not trust Watcom more than Intel and Sun (and GCC) together ;) But let's CC Jason, maybe he wants to give his opinion... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug target/42486] Parameter spilling can be merged into function prologue
--- Comment #2 from ramana at gcc dot gnu dot org 2009-12-24 16:02 --- This isn't going to happen till we teach csa and the other optimizers about load and store multiple as first class objects in the IR. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-24 16:02:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42486
[Bug libstdc++/42491] New: performance/30_threads/future/polling.cc fails at compile time
Benjamin, apparently the framework isn't passing -std=gnu++0x (I suspect isn't passing -pthread either). Can you have a look? -- Summary: performance/30_threads/future/polling.cc fails at compile time Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: paolo dot carlini at oracle dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42491
[Bug java/42409] org.eclipse.jdt.internal.compiler.batch.GCCMain not found
--- Comment #1 from jlpoole at pon dot net 2009-12-24 16:23 --- I learned from http://gcc.gnu.org/ml/java/2008-08/msg00031.html (Andrew Haley) how to invoke the test suite: make check-target-libjava Here are my results: make check-target-libjava ... [assorted make executions] ... WARNING: Couldn't find the global config file. Test Run By root on Thu Dec 24 12:21:08 2009 Native configuration is armv5tel-unknown-linux-gnueabi === libjava tests === Schedule of variations: unix Running target unix Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target. Using /usr/share/dejagnu/config/unix.exp as generic interface file for target. Using /mnt/seagate2/download/gnu/trunk/libjava/testsuite/config/default.exp as tool-and-target-specific interface file. Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.cni/cni.exp ... Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jar/jar.exp ... Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jni/jni.exp ... FAIL: calls execution - gij test FAIL: findclass2 run Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/jvmti-interp.exp ... LD_LIBRARY_PATH=. /mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/./libjava/gij -cp /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/interp/getargssize.jar -agentlib:dummyagent getargssize LD_LIBRARY_PATH=. /mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/./libjava/gij -cp /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/interp/getlocalvartable.jar -agentlib:dummyagent getlocalvartable LD_LIBRARY_PATH=. /mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/./libjava/gij -cp /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/interp/getstacktrace.jar -agentlib:dummyagent getstacktrace Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.jvmti/jvmti.exp ... Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.lang/lang.exp ... FAIL: Throw_2 execution - source compiled test FAIL: Throw_2 -findirect-dispatch execution - source compiled test FAIL: Throw_2 -O3 execution - source compiled test FAIL: Throw_2 -O3 -findirect-dispatch execution - source compiled test Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.loader/loader.exp ... Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.mauve/mauve.exp ... Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.special/special.exp ... Running /mnt/seagate2/download/gnu/trunk/libjava/testsuite/libjava.verify/verify.exp ... === libjava Summary === # of expected passes2561 # of unexpected failures6 # of untested testcases 6 make[3]: *** [check-DEJAGNU] Error 1 make[3]: Leaving directory `/mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/libjava/testsuite' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/libjava/testsuite' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/mnt/seagate2/download/gnu/build/armv5tel-unknown-linux-gnueabi/libjava' make: *** [check-target-libjava] Error 2 plug build # The above looks very encouraging which suggests that my only problem of trying to compile, as set forth in this bug, is a configuration issue. The test suite appears to be able to configure everything it needs from the environment, whereas the install environment does not. I do not know if the six unexpected failures will preclude me from compiling. Is there a way to get more detail on the failure results? Is there anything I can do to help shed more light on whatever is causing the failures? Lastly, does anyone have a suggestion on what I need to include to overcome the org.eclipse.jdt.internal.compiler.batch.GCCMain class not found error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42409
[Bug middle-end/42488] spurious strict-aliasing warning
--- Comment #5 from hjl dot tools at gmail dot com 2009-12-24 16:59 --- It is fixed by revision 145494: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00115.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42488
[Bug c++/38392] Template friend function injection
--- Comment #11 from H9XLrv5oXVNvHiUI at spambox dot us 2009-12-24 17:23 --- This is possibly the part in which gets confirmed that the code is standard compliant, although it reports the exact same paragraph you linked (the old version): http://groups.google.com/group/comp.lang.c++/tree/browse_frm/thread/493afd501c807ffe/68c709135884bac7?rnum=11_done=%2Fgroup%2Fcomp.lang.c%2B%2B%2Fbrowse_frm%2Fthread%2F493afd501c807ffe%3F#doc_38f8441247122dcd I guess that page is some kind of errata corrige? Anyway maybe I'm missing something but I see that as a conflict. If I recall correctly it is stated that the context of a injected friend function must not be ambiguous, thus meaning you have to declare it first in the correct namespace. The idea of declaration is that you inform the compiler that the function exists somewhere so that you can use it without having it defined yet. If friend function injection is just like defining the function in the parent namespace of the class and if a template exists as a type (at linking level) only when you create an instance of that type, it means the moment you instantiate the template, then the type is defined and consequently the friend function is injected, thus matching with the declaration done before, thus matching with the call that used that declaration. As I pointed in that newsgroup thread, it works fine with normal classes, and theoretically a template is just a class in the second you create an instance of it. I don't precisely understand why there should be an exception for templates. I understand not defining the function if you don't create any instance of the template, but otherwise it's a bit unclear to me why there should be this exception. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c/42492] New: cannot take address of bit-field
This is simular to bug #31541, but different version of gcc.
v4.4.2-152840-release-2.19-2009-10-27_ntv/bin/gcc/configure --disable-nls
--disable-c-mbchar --disable-plugin --disable-werror --disable-shared
--enable-languages=c,c++ --with-gmp=/emc/ucode/Linux-2x-i686/gmp-4.2.2
--with-mpfr=/emc/ucode/Linux-2x-i686/mpfr-2.4.0
--prefix=gcc4x/v4.4.2-152840-release-2.19-2009-10-27_ntv
tst.c: In function 'close_stat_io_no_exp':
tst.c:8: error: cannot take address of bit-field 'stat_rndm'
static void *__memset_native_cnst_zero(void *dest, unsigned int size);
static void *__memset_native_cnst_zero(void *dest, unsigned int size)
{
unsigned char *d = (unsigned char *)dest;
if (size = 8)
{
do { __asm__ __volatile__( movq %%xmm0, %0\n : =m (d[0]) : :
memory, xmm0); }
while (0);
d += 8;
size -= 8;
}
return (dest);
}
typedef struct S_STRUCT_STAT_IO
{
unsigned int stat_rndm : 8;
unsigned int stat_exp1 : 24;
unsigned int rndm_exp_word;
} T_STRUCT_STAT_IO;
void close_stat_io_no_exp (void);
void close_stat_io_no_exp (void)
{
T_STRUCT_STAT_IO close_stat_io;
if (__builtin_constant_p(sizeof(close_stat_io)))
__memset_native_cnst_zero((close_stat_io), (sizeof(close_stat_io)));
}
--
Summary: cannot take address of bit-field
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yakov at emc dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42492
[Bug target/35013] Incomplete check in RTL for pm() annotation
--- Comment #2 from hutchinsonandy at gcc dot gnu dot org 2009-12-24 19:54 --- Subject: Bug 35013 Author: hutchinsonandy Date: Thu Dec 24 19:53:57 2009 New Revision: 155459 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155459 Log: 2009-12-24 Andy Hutchinson hutchinsona...@gcc.gnu.org PR target/35013, 27192 * config/avr/avr.c (print_operand_address): Print correct program memory address. Add warning for large device offset addresses. (avr_assemble_integer): Ditto. (print_operand): Add warnings for incorrect addressing. (out_movqi_r_mr): Tag assembler with new address codes. (out_movhi_r_mr): Ditto. (out_movsi_r_mr): Ditto. (out_movqi_mr_r): Ditto. (out_movhi_mr_r): Ditto. (out_movsi_mr_r): Ditto. * config/avr/predicates.md (text_segment_operand): New predicate. * config/avr/avr.md (jump): Tag assembler with new address codes. (call_insn): Ditto. (call_value_insn): Ditto. (*tablejump_lib): Ditto. (*cbi): Ditto. (*sbi): Ditto. (indirect_jump): New define_expand. (jcindirect_jump): New pattern for constant expression jump. (njcindirect_jump): Renamed old indirect_jump. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/predicates.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013
[Bug target/35013] Incomplete check in RTL for pm() annotation
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2009-12-24 19:58 --- Fixed 4.5 -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35013
[Bug target/27192] call through function pointer goes to wrong address
--- Comment #7 from hutchinsonandy at gcc dot gnu dot org 2009-12-24 20:01 --- Fixed 4.5 -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27192
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap comparison failures
--- Comment #9 from zsojka at seznam dot cz 2009-12-24 20:24 --- Thank you for commiting that patch. I am also receiving bootstrap comparison failures at x86_64 (r155455, -O2 -fgcse-sm): gcc/double-int.o differs libcpp/expr.o differs r155434 without -fgcse-sm bootstraps fine (I didn't test r155455 without -fgcse-sm, yet) When I applied patch from comment #2 (it does the same as the commited patch) to r153685, it bootstraped fine as well. There are (used to be?) random cfgloopmanip.o comparison failures appearing when building from gentoo's sources (not vanilla, so I didn't report it, and I wasn't able to reproduce it) (those sources are weekly snapshots - some snapshots managed to compile, some didn't). I hope this information can be in some way useful. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug target/42457] [4.5 Regression] AVR fails to build with other than C family languages
--- Comment #5 from hutchinsonandy at gcc dot gnu dot org 2009-12-24 20:32 --- Subject: Bug 42457 Author: hutchinsonandy Date: Thu Dec 24 20:32:38 2009 New Revision: 155460 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155460 Log: 2009-12-24 Andy Hutchinson hutchinsona...@gcc.gnu.org PR target/42457 * config/avr/avr.c (avr_extra_arch_macro): Remove static. (avr_cpu_cpp_builtins): Remove. * config/avr/avr.h (avr_extra_arch_macro): Add prototype. * config/avr/avr-c.c: New File. (avr_cpu_cpp_builtins) : Add. * config/avr/t-avr: Add make information for avr-c. * config.gcc (avr-*-*): Include avr-c.o as c and cpp object. Added: trunk/gcc/config/avr/avr-c.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/t-avr -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457
[Bug target/42457] [4.5 Regression] AVR fails to build with other than C family languages
--- Comment #6 from hutchinsonandy at gcc dot gnu dot org 2009-12-24 20:33 --- Fixed 4.5 -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42457
[Bug rtl-optimization/41862] [4.5 Regression] -fgcse-sm causes bootstrap comparison failures
--- Comment #10 from zsojka at seznam dot cz 2009-12-24 20:35 --- (In reply to comment #9) When I applied patch from comment #2 (it does the same as the commited patch) to r153685, it bootstraped fine as well. With -O2 -fgcse-sm, that is. (I don't know if that was a luck, some latent bug that wasn't visible in that revision, or a new bug has been introduced to trunk since then) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41862
[Bug c++/41305] Infinite recursion with g++ at -O0
--- Comment #6 from jason at gcc dot gnu dot org 2009-12-24 21:03 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41305
[Bug rtl-optimization/42489] Function call never happened after compile with -foptimize-sibling-calls
--- Comment #3 from d dot g dot gorbachev at gmail dot com 2009-12-24 21:25 --- Some issues with -foptimize-sibling-calls were fixed in GCC 4.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug rtl-optimization/42489] Function call never happened after compile with -foptimize-sibling-calls
--- Comment #4 from t7 at gmail dot com 2009-12-24 21:29 --- (In reply to comment #3) Some issues with -foptimize-sibling-calls were fixed in GCC 4.5 Backport it to 4.4 branch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug tree-optimization/42492] cannot take address of bit-field
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-24 21:34 --- Works on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |tree-optimization Keywords||rejects-valid Known to work||4.5.0 Summary|cannot take address of bit- |cannot take address of bit- |field |field http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42492
[Bug tree-optimization/42492] cannot take address of bit-field
--- Comment #2 from yakov at emc dot com 2009-12-24 21:43 --- Subject: Re: cannot take address of bit-field I know; is there a patch that could be used for gcc-4.4.2? pinskia at gcc dot gnu dot org wrote: --- Comment #1 from pinskia at gcc dot gnu dot org 2009-12-24 21:34 --- Works on the trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42492
[Bug c++/41305] Infinite recursion with g++ at -O0
--- Comment #7 from jason at gcc dot gnu dot org 2009-12-24 21:46 --- Subject: Bug 41305 Author: jason Date: Thu Dec 24 21:46:14 2009 New Revision: 155461 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155461 Log: PR c++/41305, DR 384 * name-lookup.c (arg_assoc_class): Split out arg_assoc_class_only and arg_assoc_bases. (friend_of_associated_class_p): Remove. (arg_assoc_namespace): Don't call it. (arg_assoc_template_arg): Use arg_assoc_class_only for member template context. (arg_assoc_type): Handle UNION_TYPE and ENUMERAL_TYPE properly. * name-lookup.c (arg_assoc): Handle TEMPLATE_ID_EXPR properly. Added: trunk/gcc/testsuite/g++.dg/lookup/koenig10.C trunk/gcc/testsuite/g++.dg/lookup/koenig11.C trunk/gcc/testsuite/g++.dg/lookup/koenig12.C trunk/gcc/testsuite/g++.dg/lookup/koenig9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41305
[Bug c++/38392] Template friend function injection
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-12-16 01:08:10 |2009-12-24 21:47:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/38392] Template friend function injection
--- Comment #12 from jason at gcc dot gnu dot org 2009-12-24 21:48 --- Created an attachment (id=19387) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19387action=view) patch Here's a fix. I'm going to hold off on applying it for now since it isn't a regression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/38392] Template friend function injection
--- Comment #13 from paolo dot carlini at oracle dot com 2009-12-24 21:55 --- Cool. Should the testcase use dg-do link? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug rtl-optimization/42489] Function call never happened after compile with -foptimize-sibling-calls
--- Comment #5 from t7 at gmail dot com 2009-12-24 22:09 --- (In reply to comment #3) Some issues with -foptimize-sibling-calls were fixed in GCC 4.5 Which revision fix in trunk?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug middle-end/41674] [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main
--- Comment #8 from danglin at gcc dot gnu dot org 2009-12-24 22:13 --- This appears to be a problem with cgraph_externally_visible_p. function_and_variable_visibility sets the TREE_PUBLIC flag in decl to zeor when cgraph_externally_visible_p returns false. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
[Bug c++/38392] Template friend function injection
--- Comment #14 from jason at gcc dot gnu dot org 2009-12-24 22:14 --- Ah, good point. I've updated the patch accordingly in my local pre-4.6 git branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug c++/38392] Template friend function injection
--- Comment #15 from H9XLrv5oXVNvHiUI at spambox dot us 2009-12-24 22:15 --- Hey thank you! I'd like to test the patch if I only I'd be able to compile 4.5 successfully. You have any idea on when could this patch make it to a final release? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38392
[Bug rtl-optimization/42489] Function call never happened after compile with -foptimize-sibling-calls
--- Comment #6 from t7 at gmail dot com 2009-12-24 22:44 --- Cause endless maximum cpu usage in application run-time. -- t7 at gmail dot com changed: What|Removed |Added Severity|normal |major http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug bootstrap/42493] New: Failure building gcc-trunk with multilib support
checking if ccache gcc -m32 supports -fno-rtti -fno-exceptions... no checking for ccache gcc -m32 option to produce PIC... -fPIC -DPIC checking if ccache gcc -m32 PIC flag -fPIC -DPIC works... yes checking if ccache gcc -m32 static flag -static works... no checking if ccache gcc -m32 supports -c -o file.o... yes checking if ccache gcc -m32 supports -c -o file.o... (cached) yes checking whether the ccache gcc -m32 linker (/usr/lib64/gcc/x86_64-slackware-linux/4.3.3/../../../../x86_64-slackware-linux/bin/ld -m elf_x86_64 -m elf_i386) supports shared libraries... yes checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-zlib] Error 1 O/S not supported??? -- Summary: Failure building gcc-trunk with multilib support Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: t7 at gmail dot com GCC build triplet: x86_64-slackware-linux GCC host triplet: x86_64-slackware-linux GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42493
[Bug bootstrap/42493] Failure building gcc-trunk with multilib support
--- Comment #1 from t7 at gmail dot com 2009-12-24 23:52 --- --with-system-zlib is not default. -- t7 at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42493
[Bug c++/42471] No return value from operator =() is accepted by the compiler
--- Comment #2 from Curatica at gmail dot com 2009-12-25 00:08 --- Thanks (not sure what 4.1.0 referred to)... -- Curatica at gmail dot com changed: What|Removed |Added Status|RESOLVED|VERIFIED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42471
[Bug rtl-optimization/42489] Function call never happened after compile with -foptimize-sibling-calls
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug tree-optimization/42492] cannot take address of bit-field
--- Comment #3 from hjl dot tools at gmail dot com 2009-12-25 01:24 --- It may be fixed by revision 151260: http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg6.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-12-25 01:24:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42492
[Bug c++/42470] Conversion Constructor not accepted/recognized
--- Comment #2 from Curatica at gmail dot com 2009-12-25 02:04 ---
Please, understand that for me this is just a disinterested, academic
discussion: no offense. I am not sure that I agree with the theory.
The standard (8.5.1) states that:
T x = a;
is a copy-initialization but does not infer that this has anything to do with
the copy constructor. If I fix the source by adding const to the copy c-tor
argument:
Base( const Base b ) { /*...*/ }
the code compiles indeed but there is no evidence whatsoever that the copy
c-tor is being invoked when the code
Base b2 = 5;
is executed (as one could see, the copy c-tor prints a specific text to stdout,
which does not appear in this case). Furthermore, if I take out the copy c-tor
altogether, the code compiles and executes correctly. In either case, it seems
clear to me that
Base( int a ) { /*...*/ }
is invoked. This is in accordance to 12.3.1 Conversion by constructor in the
standard [class.conv.ctor].
My guess is that different people interpreted the standard differently: the
machine code is generated correctly in all cases but the compilation error
which depends on the constatness or lack thereof of the copy c-tor argument
is bogus.
--
Curatica at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42470
[Bug c++/42472] class members not getting assigned access thru another method
--- Comment #2 from k_suresh_babu at yahoo dot com 2009-12-25 02:43 ---
Subject: Re: class members not getting assigned access thru another method
Hi,
So a constructor can't call another method if that is the case then it is ok.
You can close the issue.
regards,
sureshbk.
--- On Wed, 12/23/09, redi at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
wrote:
From: redi at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org
Subject: [Bug c++/42472] class members not getting assigned access thru
another method
To: k_suresh_b...@yahoo.com
Date: Wednesday, December 23, 2009, 5:09 AM
--- Comment #1 from redi at gcc dot gnu dot org
2009-12-23 11:09 ---
C++ is not java, you cannot delegate to another constructor
like this:
primes::primes(ulong p):maxp(p) { primes(); }
That creates a temporary object of type primes, it does not
call the
constructor.
Therefore primes::i and primes::p are not initialised by
the primes(long)
constructor.
--
redi at gcc dot gnu dot org changed:
What
|Removed
|Added
Status|UNCONFIRMED
|RESOLVED
Resolution|
|INVALID
Version|unknown
|4.3.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42472
--- You are receiving this mail because: ---
You reported the bug, or are watching the reporter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42472
[Bug rtl-optimization/42489] Opt bug -foptimize-sibling-calls function call stalled! dead-lock, cpu max
--- Comment #7 from t7 at gmail dot com 2009-12-25 02:46 --- (In reply to comment #3) Some issues with -foptimize-sibling-calls were fixed in GCC 4.5 False. Browsed all recently committed gcc svn change-logs saw no -foptimize-sibling-calls related fixes. Updated gcc-trunk svn, compiled gcc-trunk. Tested gcc version 4.5.0 20091224 (experimental) Revision 155461 MINGW64-1684 Referential numerous bug-reports: * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41424 * http://sourceforge.net/projects/mingw-w64/forums/forum/723797/topic/3482477 Very mingw-w64 specific I think. -- t7 at gmail dot com changed: What|Removed |Added Known to fail||4.4.3 4.5.0 Summary|Function call never happened|Opt bug -foptimize-sibling- |after compile with -|calls function call stalled! |foptimize-sibling-calls |dead-lock, cpu max Version|4.4.3 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug rtl-optimization/42489] Opt bug -foptimize-sibling-calls function call stalled! dead-lock, cpu max
--- Comment #8 from t7 at gmail dot com 2009-12-25 02:51 --- No simple test-case code can be provided you have to read libxml2 source error.c about less then 1000 lines. Without running program in the gdb, fprintf to stderr in the beginning of the __xmlRaiseError() there was no output, ran in gdb there was output and dead-lock cpu running 100% it contributes to global warming. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42489
[Bug c/42494] New: Regression on dead-code-elimination: GCC 4.2.1 generates better code than 4.4.0
For the following code:
extern void func();
extern char outbuf[];
extern int outcnt;
extern int bool_var;
void test ()
{
char flags;
flags = 0;
outcnt = 0;
if (outcnt == 1) func ();
if (outcnt == 1) func ();
if (outcnt == 1) func ();
if (bool_var) flags = 2;
outbuf[outcnt] = flags;
if (outcnt == 1) func ();
}
I found that GCC 4.4.0 generates the following code:
.code 16
.file outcnt.c
.text
.align 2
.global test
.code 16
.thumb_func
.type test, %function
test:
push{r4, lr}
ldr r3, .L7
mov r2, #0
str r2, [r3]
ldr r3, .L7+4
mov r2, #2
ldr r3, [r3]
cmp r3, #0
bne .L3
mov r2, #0
.L3:
ldr r3, .L7
ldr r1, .L7+8
ldr r3, [r3]
strbr2, [r1, r3]
cmp r3, #1
bne .L5
bl func
.L5:
@ sp needed for prologue
pop {r4, pc}
.L8:
.align 2
.L7:
.word outcnt
.word bool_var
.word outbuf
.size test, .-test
.ident GCC: (GNU) 4.4.0
, while GCC 4.2.1 generates the following code:
.code 16
.file outcnt.c
.text
.align 2
.global test
.code 16
.thumb_func
.type test, %function
test:
push{lr}
ldr r2, .L6
mov r3, #0
str r3, [r2]
ldr r3, .L6+4
ldr r3, [r3]
cmp r3, #0
beq .L2
mov r2, #2
b .L4
.L2:
mov r2, #0
.L4:
ldr r3, .L6+8
@ sp needed for prologue
strbr2, [r3]
pop {pc}
.L7:
.align 2
.L6:
.word outcnt
.word bool_var
.word outbuf
.size test, .-test
.ident GCC: (GNU) 4.2.1
The code snippet has a lot of dead code that is not completely eliminated by
gcc 4.4.0 (but correctly eliminated by gcc 4.2.1).
Because outcnt == 0, all lines 'if (outcnt == 1)' can be eliminated. Because
outbuf and outcnt are global external symbols of different types, they can not
be aliased, so the last statement can be also eliminated.
gcc 4.2.1 output is 40 bytes, gcc 4.4.0 output is 52 bytes. It also inserts 'bl
func'.
This code snippet was extracted from gzip benchmark, but got changed quite a
bit.
--
Summary: Regression on dead-code-elimination: GCC 4.2.1 generates
better code than 4.4.0
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sliao at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42494
[Bug target/42495] New: redundant memory load
Compile the attached test case with options -mthumb -Os -fpic, gcc generates:
goo:
push{r3, r4, r5, lr}
ldr r4, .L7
ldr r3, .L7+4// A
.LPIC0:
add r4, pc
ldr r3, [r4, r3] // B
ldr r3, [r3]
mov r5, r0
ldr r0, [r3]
cmp r0, #0
beq .L2
mov r1, r5
bl foo
.L2:
ldr r3, [r5]
mov r0, #0
cmp r3, #0
beq .L3
ldr r2, .L7+4 // C
ldr r2, [r4, r2] // D
ldr r2, [r2, #4]
ldr r2, [r2]
cmp r3, r2
beq .L3
ldr r0, [r3]
.L3:
@ sp needed for prologue
pop {r3, r4, r5}
pop {r1}
bx r1
.L7:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4)
.word gObj(GOT)
Notice instructions A,B,C,D, they load the address of global variable gObj
twice.
When compiled with options -mthumb -O2 -fpic, gcc generates:
goo:
push{r4, r5, r6, lr}
ldr r4, .L8
ldr r5, .L8+4 // E
.LPIC0:
add r4, pc
ldr r3, [r4, r5] // F
ldr r3, [r3]
mov r6, r0
ldr r0, [r3]
cmp r0, #0
bne .L7
.L2:
ldr r3, [r6]
mov r0, #0
cmp r3, #0
beq .L3
ldr r2, [r4, r5] // G
ldr r2, [r2, #4] // H
ldr r2, [r2]
cmp r2, r3
beq .L3
ldr r0, [r3]
.L3:
@ sp needed for prologue
pop {r4, r5, r6}
pop {r1}
bx r1
.L7:
mov r1, r6
bl foo
b .L2
.L9:
.align 2
.L8:
.word _GLOBAL_OFFSET_TABLE_-(.LPIC0+4)
.word gObj(GOT)
Instructions E,F,G do the same thing, but with one less memory load
instruction. It uses the same number of instructions. -Os should do the same
optimization.
Actually -O2 result is still not optimal. If we store the result of F into r4,
we can directly use r4 in instruction H, so G can also be removed.
--
Summary: redundant memory load
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: carrot at google dot com
GCC build triplet: i686-linux
GCC host triplet: i686-linux
GCC target triplet: arm-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug target/42495] redundant memory load
--- Comment #1 from carrot at google dot com 2009-12-25 07:51 --- Created an attachment (id=19388) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19388action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
[Bug target/42495] redundant memory load
--- Comment #2 from carrot at google dot com 2009-12-25 07:52 --- instruction. It uses the same number of instructions. -Os should do the same It uses the same number of registers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42495
