[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #30 from rguenther at suse dot de rguenther at suse dot de 2012-08-23 07:13:13 UTC --- On Wed, 22 Aug 2012, stevenb.gcc at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #29 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-22 17:33:00 UTC --- I thought that loop header copying wouldn't need to insert new PHI nodes and thus can do with TODO_update_ssa_no_phi if we are in loop-closed SSA form, but appearantly that is not the case (I didn't inverstigate further here, but possibly that's just because virtual operands are not in loop-closed SSA form). I'll experiment with VOPs in LC-SSA. You might have seen the patch I posted - it passed testing and I will install it today.
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de
2012-08-23 07:29:04 UTC ---
On Wed, 22 Aug 2012, steven at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
Steven Bosscher steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2012-08-22
19:26:03 UTC ---
(In reply to comment #4)
Wouldn't this patch disable all loop detection for loops with exceptions and
so
on in them? That seems a rather big hammer to this problem. It should be
enough
to check only for EH_ABNORMAL.
Well, yes - the patch isn't really a fix for the issue but addresses
something I noticed in the loop detection code. Namely that it happily
detects a loop like (1)
header
| \
(ab) |
| /
latch
thus, a loop where there isn't a single path in the CFG that is
non-abnormal/EH. That isn't a useful loop. Loops with EH are still
handled as they look like (2)
header ---
| \
BB \
/ \ \
(eh) (fallthru)|
/ | |
latch
thus, EH edges should also not form loops but always act as loop
exits.
That patch masks the underlying issue of course, but I still think
loops of the form (1) are not useful (we cannot perform a reasonable
loop transform on it - we can handle abnormal / eh exits and entries
but not loop paths).
What caused the ICE to appear anyway? There is a problem I can see in
dfs_enumerate_from that could cause it to ICE.
At the point of the ICE, we have the following CFG (cc1 -O2 -ftracer):
(gdb) p current_pass-name
$5 = 0x13195b0 local-pure-const
(gdb) p brief_dump_cfg(stderr,-1)
;; basic block 2, loop depth 0, count 0, freq 6667, maybe hot
;; prev block 0, next block 3, flags: (NEW, REACHABLE)
;; pred: ENTRY [100.0%] (FALLTHRU,EXECUTABLE)
;; succ: 3 [100.0%] (FALLTHRU,EXECUTABLE)
;; basic block 3, loop depth 0, count 0, freq 6667, maybe hot
;; prev block 2, next block 4, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP)
;; pred: 2 [100.0%] (FALLTHRU,EXECUTABLE)
;; succ: 5 [100.0%] (FALLTHRU,IRREDUCIBLE_LOOP,EXECUTABLE)
;; basic block 4, loop depth 0, count 0, freq 0
;; Invalid sum of incoming frequencies , should be 0
;; prev block 3, next block 5, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP)
;; pred: 5 [33.3%] (ABNORMAL,IRREDUCIBLE_LOOP,EXECUTABLE)
;; succ: 5 [100.0%] (FALLTHRU,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
;; basic block 5, loop depth 1, count 0, freq 1, maybe hot
;; prev block 4, next block 6, flags: (NEW, REACHABLE)
;; pred: 4 [100.0%] (FALLTHRU,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
;; 6 [100.0%] (FALLTHRU,DFS_BACK,EXECUTABLE)
;; 3 [100.0%] (FALLTHRU,IRREDUCIBLE_LOOP,EXECUTABLE)
;; succ: 4 [33.3%] (ABNORMAL,IRREDUCIBLE_LOOP,EXECUTABLE)
;; 6 [33.3%] (ABNORMAL,EXECUTABLE)
;; 7 [33.3%] (ABNORMAL,EXECUTABLE)
;; basic block 6, loop depth 1, count 0, freq , maybe hot
;; prev block 5, next block 7, flags: (NEW, REACHABLE)
;; pred: 5 [33.3%] (ABNORMAL,EXECUTABLE)
;; succ: 5 [100.0%] (FALLTHRU,DFS_BACK,EXECUTABLE)
;; basic block 7, loop depth 0, count 0, freq , maybe hot
;; prev block 6, next block 1, flags: (NEW, REACHABLE)
;; pred: 5 [33.3%] (ABNORMAL,EXECUTABLE)
;; succ: EXIT [100.0%]
Or in human-readable form:
ENTRY
|
V
|
2(0)
|
|
V
|
3(0)
|
\
\
\
\
\
\
++ | +-+
| \ V / |
| \ | /|
+-4(1)--5(1)--6(1)-+
(a) | (a)
|
|(a)
|
7(0)
|
EXIT
where (a) denotes abnormal edge, of course, and (0) or (1) is the loop depth
at this point.
The loop detected here is the region with the abnormal edges, for blocks 4, 5,
and 6. The detected loop has header bb 5 and latch bb 6, which is not
clearly
wrong: this is just two loops with the same header. But this confuses
dfs_enumerate_from, which does a reverse DFS from basic block 5 with predicate
glb_enum_p. The DFS visits block 5, 4, and 6, but dfs_enumerate_from is told
to
expect to visit only 2 basic blocks, not 3. The reason it sees 3 is that
glb_enum_p is this:
/* Enumeration predicate for get_loop_body_with_size. */
static bool
glb_enum_p (const_basic_block bb, const void *glb_loop)
{
const struct loop *const loop = (const struct loop *) glb_loop;
return (bb != loop-header
dominated_by_p (CDI_DOMINATORS, bb, loop-header));
}
called with loop-header == bb5, and called with bb==4 and bb==6. And
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #11 from rguenther at suse dot de rguenther at suse dot de 2012-08-23 07:36:46 UTC --- On Wed, 22 Aug 2012, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-08-22 21:33:18 UTC --- I think the right fix for this bug is to use disambiguate_multiple_latches in the loop updating code (fix_loop_structure), but I'm not sure where to put it. Not sure - we can handle multiple latches just fine (loop-latch will be NULL). But I see the loop state does not reflect that. Maybe Index: gcc/cfgloopmanip.c === --- gcc/cfgloopmanip.c (revision 190613) +++ gcc/cfgloopmanip.c (working copy) @@ -1715,6 +1716,9 @@ fix_loop_structure (bitmap changed_bbs) } } + if (!loop_state_satisfies_p (LOOPS_MAY_HAVE_MULTIPLE_LATCHES)) +disambiguate_loops_with_multiple_latches (); + if (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)) create_preheaders (CP_SIMPLE_PREHEADERS); which matches the order in which loop_optimizer_init calls it. Richard.
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-23 Ever Confirmed|0 |1
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #12 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-23 07:56:13 UTC --- The patch is of couse a big hammer because it has a cost, but IMHO it still makes sense. I'm not convinced. GCC has always detected this kind of loop (even the old non-cfg loop code recognizes this kind of loop) and it has never caused any problems before your patch to keep the loop structure up-to-date. To me, this means that the fix should be in the loop updating, not in abandoning a decades-old behavior of the compiler.
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #13 from rguenther at suse dot de rguenther at suse dot de 2012-08-23 08:07:18 UTC --- On Thu, 23 Aug 2012, rguenther at suse dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #11 from rguenther at suse dot de rguenther at suse dot de 2012-08-23 07:36:46 UTC --- On Wed, 22 Aug 2012, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org 2012-08-22 21:33:18 UTC --- I think the right fix for this bug is to use disambiguate_multiple_latches in the loop updating code (fix_loop_structure), but I'm not sure where to put it. Not sure - we can handle multiple latches just fine (loop-latch will be NULL). But I see the loop state does not reflect that. Maybe Index: gcc/cfgloopmanip.c === --- gcc/cfgloopmanip.c (revision 190613) +++ gcc/cfgloopmanip.c (working copy) @@ -1715,6 +1716,9 @@ fix_loop_structure (bitmap changed_bbs) } } + if (!loop_state_satisfies_p (LOOPS_MAY_HAVE_MULTIPLE_LATCHES)) +disambiguate_loops_with_multiple_latches (); + if (loops_state_satisfies_p (LOOPS_HAVE_PREHEADERS)) create_preheaders (CP_SIMPLE_PREHEADERS); which matches the order in which loop_optimizer_init calls it. Doesn't fix the testcase. We fail during verify_loop_structure and the loop state _does_ have LOOPS_MAY_HAVE_MULTIPLE_LATCHES set. Now, for the testcase we at this point just have a single loop left (we don't recognize the loop with the abnormal path from header to latch). Btw, I'm looking at the reduced testcase in the patch (yes, that's a slightly different situation but simpler to analyze and fails the same way). So what's wrong here is indeed loop-num_nodes (we don't account the other loop to loop 1 and we do not properly mark the loop as having multiple latches). Already the input to tracer is wrong in that we have lost a loop, the one with abnormal path from latch to header (which we _do_ reject during loop discovery!). So what happens is that we turn this loop into one that would have been recognized, swap header and latch and thus get the abnormal edge to a tolerated place (header to latch). That inconsistency is what my patch tries to address (another way would be to simply allow EH/abnormal latch - header edges as well). So, tracer transforms bb2 | bb3 | ^ | |(ab) v | bb4 (loop1 header) | | \ bb5 (loop1 latch)v BB6 - BB1 by duplicating bb3 to bb2 | bb7 (duplicate of bb3) | ---bb4 (loop1 header) (ab) | / \ \ | | bb5 (loop1 latch) bb3 but it does not add bb3 to loop1, nor zero out its latch and setting may-have-multiple-latches. The cfghook only takes care of updating the loop structure with respect to the _new_ basic block but does not consider that the old one magically becomes part of a loop. But IMHO the bug is either that we don't consider it part of the loop before this transform or that we do consider it part of the loop after the transform! Which is what my patch tries to address. Richard.
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #14 from rguenther at suse dot de rguenther at suse dot de 2012-08-23 08:10:15 UTC --- On Thu, 23 Aug 2012, stevenb.gcc at gmail dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #12 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot com 2012-08-23 07:56:13 UTC --- The patch is of couse a big hammer because it has a cost, but IMHO it still makes sense. I'm not convinced. GCC has always detected this kind of loop (even the old non-cfg loop code recognizes this kind of loop) and it has never caused any problems before your patch to keep the loop structure up-to-date. To me, this means that the fix should be in the loop updating, not in abandoning a decades-old behavior of the compiler. It's inconsistent in that it considers header | ^ (ab) | v | latch a loop but not header | ^ | (ab) v | latch and tracer rotates this loop by swapping dominance relationship between header and latch but not makes the non-loop magically a loop. My patch makes both not a loop.
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-23 08:37:24 UTC --- Author: redi Date: Thu Aug 23 08:37:19 2012 New Revision: 190616 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190616 Log: PR libstdc++/54354 * doc/xml/manual/status_cxx2011.xml: Note missing manipulators. * doc/html/*: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/api.html trunk/libstdc++-v3/doc/html/faq.html trunk/libstdc++-v3/doc/html/index.html trunk/libstdc++-v3/doc/html/manual/abi.html trunk/libstdc++-v3/doc/html/manual/algorithms.html trunk/libstdc++-v3/doc/html/manual/api.html trunk/libstdc++-v3/doc/html/manual/appendix_contributing.html trunk/libstdc++-v3/doc/html/manual/appendix_free.html trunk/libstdc++-v3/doc/html/manual/appendix_gpl.html trunk/libstdc++-v3/doc/html/manual/appendix_porting.html trunk/libstdc++-v3/doc/html/manual/atomics.html trunk/libstdc++-v3/doc/html/manual/backwards.html trunk/libstdc++-v3/doc/html/manual/bk01pt02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch17s03.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch18s03.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch19s02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch19s07.html trunk/libstdc++-v3/doc/html/manual/bk01pt03ch21s02.html trunk/libstdc++-v3/doc/html/manual/bk01pt03pr01.html trunk/libstdc++-v3/doc/html/manual/concurrency.html trunk/libstdc++-v3/doc/html/manual/configure.html trunk/libstdc++-v3/doc/html/manual/containers.html trunk/libstdc++-v3/doc/html/manual/debug.html trunk/libstdc++-v3/doc/html/manual/diagnostics.html trunk/libstdc++-v3/doc/html/manual/documentation_hacking.html trunk/libstdc++-v3/doc/html/manual/extensions.html trunk/libstdc++-v3/doc/html/manual/facets.html trunk/libstdc++-v3/doc/html/manual/index.html trunk/libstdc++-v3/doc/html/manual/intro.html trunk/libstdc++-v3/doc/html/manual/io.html trunk/libstdc++-v3/doc/html/manual/iterators.html trunk/libstdc++-v3/doc/html/manual/localization.html trunk/libstdc++-v3/doc/html/manual/memory.html trunk/libstdc++-v3/doc/html/manual/numerics.html trunk/libstdc++-v3/doc/html/manual/parallel_mode.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures_design.html trunk/libstdc++-v3/doc/html/manual/policy_data_structures_using.html trunk/libstdc++-v3/doc/html/manual/profile_mode.html trunk/libstdc++-v3/doc/html/manual/status.html trunk/libstdc++-v3/doc/html/manual/strings.html trunk/libstdc++-v3/doc/html/manual/support.html trunk/libstdc++-v3/doc/html/manual/test.html trunk/libstdc++-v3/doc/html/manual/using.html trunk/libstdc++-v3/doc/html/manual/using_concurrency.html trunk/libstdc++-v3/doc/html/manual/using_dynamic_or_shared.html trunk/libstdc++-v3/doc/html/manual/using_exceptions.html trunk/libstdc++-v3/doc/html/manual/using_headers.html trunk/libstdc++-v3/doc/html/manual/using_macros.html trunk/libstdc++-v3/doc/html/manual/utilities.html trunk/libstdc++-v3/doc/xml/manual/status_cxx2011.xml
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #15 from stevenb.gcc at gmail dot com stevenb.gcc at gmail dot
com 2012-08-23 08:49:32 UTC ---
On Thu, Aug 23, 2012 at 10:07 AM, rguenther at suse dot de
gcc-bugzi...@gcc.gnu.org wrote:
Already the input to tracer is wrong in that we have lost
a loop, the one with abnormal path from latch to header (which
we _do_ reject during loop discovery!).
But this isn't a natural loop. It's an irreducible loop with loop
entries in basic block 3 and basic block 4 (in the pre-tracer CFG from
comment #7) and loop discovery doesn't record irreducible loop.
What tracer does here is known as node splitting to make an
irreducible region reducible. I don't think it's a
intentional/conscious node splitting but tracer does have the effect
of node splitting. After tracer, the loop with bbs {4,5,3} is a
natural loop and the CFG is reducible.
So what happens is
that we turn this loop into one that would have been recognized,
swap header and latch and thus get the abnormal edge to a tolerated
place (header to latch). That inconsistency is what my patch tries
to address (another way would be to simply allow EH/abnormal
latch - header edges as well).
But with your patch we'd also reject all already reducible loops if
there are only paths with one or more abnormal edges from the loop
header to the latch. That is more conservative than necessary. Also,
AFAIU, with your patch we'd reduce loops with a finally block
(something like
for(;;){try{...maybe_throw;...;if(...)break;}finally{...}}) because
all paths to the loop latch would go through the finally block via EH
edges.
but it does not add bb3 to loop1, nor zero out its latch
and setting may-have-multiple-latches.
That, to me, is the bug we should try to solve here.
The cfghook
only takes care of updating the loop structure with
respect to the _new_ basic block but does not consider
that the old one magically becomes part of a loop.
I think it may be possible to construct a test case just like this one
with an initially irreducible CFG that tracer makes reducible.
Anyway, consider this test case, which is the pre-tracer CFG but
without abnormal edges:
void do_something_1 (void);
void do_something_2 (void);
int some_cond (void);
void make_bb_non_empty ();
void
foo (void)
{
bb2:
make_bb_non_empty ();
goto bb3;
bb4:
switch (some_cond ())
{
case 1:
goto bb3;
case 2:
goto bb5;
default:
goto bb6;
}
bb3:
do_something_1 ();
goto bb4;
bb5:
do_something_2 ();
goto bb4;
bb6:
return;
}
This gives the following CFG in the .129t.cddce2 dump:
; 3 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6 7
;;
;; Loop 1
;; header 5, latch 4
;; depth 1, outer 0
;; nodes: 5 4 3 6
;;
;; Loop 2
;; header 3, latch 6
;; depth 2, outer 1
;; nodes: 3 6
ENTRY
|
V
|
2(0)
|
|
V
|
| +--4(1)-+
| | |
| V ^
| | |
| | +
| + /
| | /
5(1)--3(2)--6(2)-+
/\ |
/ +-+
/
|
V
|
7(0)
|
EXIT
So now the loop {5,4,3,6} is detected, even though the CFG is
basically the same as the pre-tracer one from comment #7 (only
difference is that the critical edge 3,5 in the above CFG is split
to give basic block 4.
Makes me wonder why the loop isn't recognized in the original test case...
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #16 from Steven Bosscher steven at gcc dot gnu.org 2012-08-23 08:53:04 UTC --- (In reply to comment #15) Makes me wonder why the loop isn't recognized in the original test case... Ah, maybe because bb3 has an abnormal predecessor and is therefore ignored as a potential loop header? /* If we have an abnormal predecessor, do not consider the loop (not worth the problems). */ if (bb_has_abnormal_pred (header)) continue; Which brings things back to my question why this kind of loop header is rejected! :-)
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #17 from rguenther at suse dot de rguenther at suse dot de
2012-08-23 09:19:04 UTC ---
On Thu, 23 Aug 2012, steven at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #16 from Steven Bosscher steven at gcc dot gnu.org 2012-08-23
08:53:04 UTC ---
(In reply to comment #15)
Makes me wonder why the loop isn't recognized in the original test case...
Ah, maybe because bb3 has an abnormal predecessor and is therefore ignored as
a
potential loop header?
/* If we have an abnormal predecessor, do not consider the
loop (not worth the problems). */
if (bb_has_abnormal_pred (header))
continue;
Which brings things back to my question why this kind of loop header is
rejected! :-)
Because gimple_split_edge doesn't like to split abnormal edges,
called via force_single_succ_latches (). So we do definitely
not allow abnormal latch - header edges. Still abnormal loop entries
should be fine. So,
Index: gcc/cfgloop.c
===
--- gcc/cfgloop.c (revision 190613)
+++ gcc/cfgloop.c (working copy)
@@ -400,24 +400,21 @@ flow_loops_find (struct loops *loops)
{
edge_iterator ei;
- /* If we have an abnormal predecessor, do not consider the
-loop (not worth the problems). */
- if (bb_has_abnormal_pred (header))
- continue;
-
FOR_EACH_EDGE (e, ei, header-preds)
{
basic_block latch = e-src;
- gcc_assert (!(e-flags EDGE_ABNORMAL));
-
/* Look for back edges where a predecessor is dominated
by this block. A natural loop has a single entry
node (header) that dominates all the nodes in the
loop. It also has single back edge to the header
from a latch node. */
if (latch != ENTRY_BLOCK_PTR
- dominated_by_p (CDI_DOMINATORS, latch, header))
+ dominated_by_p (CDI_DOMINATORS, latch, header)
+ /* We cannot make latches simple by splitting the
+latch - header edge if the latch edge is abnormal. */
+ (single_succ_p (latch)
+ || !(e-flags EDGE_ABNORMAL)))
{
/* Shared headers should be eliminated by now. */
SET_BIT (headers, header-index);
should work. But doesn't fix the testcase (of course).
Richard.
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #18 from rguenther at suse dot de rguenther at suse dot de 2012-08-23 09:22:54 UTC --- On Thu, 23 Aug 2012, rguenther at suse dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #17 from rguenther at suse dot de rguenther at suse dot de 2012-08-23 09:19:04 UTC --- On Thu, 23 Aug 2012, steven at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695 --- Comment #16 from Steven Bosscher steven at gcc dot gnu.org 2012-08-23 08:53:04 UTC --- (In reply to comment #15) Makes me wonder why the loop isn't recognized in the original test case... Ah, maybe because bb3 has an abnormal predecessor and is therefore ignored as a potential loop header? /* If we have an abnormal predecessor, do not consider the loop (not worth the problems). */ if (bb_has_abnormal_pred (header)) continue; Which brings things back to my question why this kind of loop header is rejected! :-) Because gimple_split_edge doesn't like to split abnormal edges, called via force_single_succ_latches (). So we do definitely not allow abnormal latch - header edges. Still abnormal loop entries should be fine. So, But we can't create pre-headers then, too. So optimizers that want pre-headers would be confused (well, or ICE). Why can we not split abnormal edges?
[Bug middle-end/52939] [4.7/4.8 Regression] ice in gimple_get_virt_method_for_binfo with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52939 --- Comment #10 from Martin Jambor jamborm at gcc dot gnu.org 2012-08-23 09:31:14 UTC --- (In reply to comment #9) Is the fix for this in a released version of GCC? If I understand our web ViewCVS correctly, the 4.7.1 release was based on revision 188597 and I have committed the patch to the release branch as revision 186489. So yes, it should be in the 4.7.1 release.
[Bug libstdc++/54354] TODO extended iomanip manipulators std::get_time and std::put_time (C++11, section 27.7.5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54354 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ABI --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-23 09:33:37 UTC --- This is also because of the ABI: I did the money ones but then noticed that in C++11 time has an additional virtual. It's also a bit discussed in the mailing list.
[Bug c++/20420] Incorrectly Accepts double declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20420 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-08-23 09:44:12 UTC --- Author: paolo Date: Thu Aug 23 09:44:08 2012 New Revision: 190618 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190618 Log: /cp 2012-08-23 Paolo Carlini paolo.carl...@oracle.com PR c++/20420 * name-lookup.c (supplement_binding_1): Handle specially enums only in class templates. (validate_nonmember_using_decl): Enforce 7.3.3/10 about duplicate using declarations at function scope. /testsuite 2012-08-23 Paolo Carlini paolo.carl...@oracle.com PR c++/20420 * g++.dg/lookup/using53.C: New. Added: trunk/gcc/testsuite/g++.dg/lookup/using53.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #19 from Steven Bosscher steven at gcc dot gnu.org 2012-08-23
09:44:18 UTC ---
FWIW, applying the transformation tracer performs on the test case by hand:
void
foo (const void * * p)
{
void *labs[] = { l1, l2, l3 };
void *gotovar;
long unsigned int p0;
long unsigned int t7;
long unsigned int t13;
gotovar = p;
p0 = (long unsigned int) gotovar;
t13 = p0 + 8;
p = (const void **) t13;
goto bb5;
l1:
gotovar = p;
p0 = (long unsigned int) gotovar;
t7 = p0 + 8;
p = (const void **) t7;
goto bb5;
bb5:
goto *gotovar;
l2:
gotovar = p;
goto bb5;
l3:
return;
}
This compiles without problem. Gives:
Disambiguating loop 1 with multiple latches
Merged latch edges of loop 1
;; 2 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 7 5 6
;;
;; Loop 1
;; header 7, latch 4
;; depth 1, outer 0
;; nodes: 7 4 5 3
;; 2 succs { 7 }
;; 3 succs { 4 }
;; 4 succs { 7 }
;; 7 succs { 3 5 6 }
;; 5 succs { 4 }
;; 6 succs { 1 }
[Bug target/49244] no intrinsics to emit 'lock bts' and 'lock btc'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49244 Michał Górny mgorny at gentoo dot org changed: What|Removed |Added CC||mgorny at gentoo dot org --- Comment #3 from Michał Górny mgorny at gentoo dot org 2012-08-23 09:46:56 UTC --- I believe that this became more important with C++11 atomic, and a separate intrinsics will be not be enough anymore. I believe that GCC should be able to optimize out such a simple cases.
[Bug c/54355] New: ICE on invalid code in switch statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54355 Bug #: 54355 Summary: ICE on invalid code in switch statement Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jay.f...@gmail.com Created attachment 28067 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28067 test case On the attached test case I get: $ cc1 reduced.c f reduced.c: In function 'f': reduced.c:5:1: error: a label can only be part of a statement and a declaration is not a statement a b ^ reduced.c:5:1: error: unknown type name 'a' reduced.c:5:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before '' token a b ^ reduced.c:5:5: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I'm using trunk revision 190616 on x86_64-unknown-linux-gnu. Credit: test case was reduced by C-Reduce: http://embed.cs.utah.edu/creduce/
[Bug c++/20420] Incorrectly Accepts double declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20420 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-23 09:53:40 UTC --- Fixed for 4.8.0.
[Bug c++/10200] Weird clash with same names in different scopes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10200 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #21 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-23 10:14:16 UTC --- Jason, noticed this very, very old issue which however clang too fixed only this March. Wondered if you have tips, believe it would be easy to fix in our front-end too, what else...
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #20 from rguenther at suse dot de rguenther at suse dot de
2012-08-23 11:00:29 UTC ---
On Thu, 23 Aug 2012, rguenther at suse dot de wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #17 from rguenther at suse dot de rguenther at suse dot de
2012-08-23 09:19:04 UTC ---
On Thu, 23 Aug 2012, steven at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #16 from Steven Bosscher steven at gcc dot gnu.org 2012-08-23
08:53:04 UTC ---
(In reply to comment #15)
Makes me wonder why the loop isn't recognized in the original test case...
Ah, maybe because bb3 has an abnormal predecessor and is therefore ignored
as a
potential loop header?
/* If we have an abnormal predecessor, do not consider the
loop (not worth the problems). */
if (bb_has_abnormal_pred (header))
continue;
Which brings things back to my question why this kind of loop header is
rejected! :-)
Because gimple_split_edge doesn't like to split abnormal edges,
called via force_single_succ_latches (). So we do definitely
not allow abnormal latch - header edges. Still abnormal loop entries
should be fine. So,
Index: gcc/cfgloop.c
===
--- gcc/cfgloop.c (revision 190613)
+++ gcc/cfgloop.c (working copy)
@@ -400,24 +400,21 @@ flow_loops_find (struct loops *loops)
{
edge_iterator ei;
- /* If we have an abnormal predecessor, do not consider the
-loop (not worth the problems). */
- if (bb_has_abnormal_pred (header))
- continue;
-
FOR_EACH_EDGE (e, ei, header-preds)
{
basic_block latch = e-src;
- gcc_assert (!(e-flags EDGE_ABNORMAL));
-
/* Look for back edges where a predecessor is dominated
by this block. A natural loop has a single entry
node (header) that dominates all the nodes in the
loop. It also has single back edge to the header
from a latch node. */
if (latch != ENTRY_BLOCK_PTR
- dominated_by_p (CDI_DOMINATORS, latch, header))
+ dominated_by_p (CDI_DOMINATORS, latch, header)
+ /* We cannot make latches simple by splitting the
+latch - header edge if the latch edge is abnormal. */
+ (single_succ_p (latch)
+ || !(e-flags EDGE_ABNORMAL)))
{
/* Shared headers should be eliminated by now. */
SET_BIT (headers, header-index);
should work. But doesn't fix the testcase (of course).
Btw, another idea would be to make labels that are target of
abnormal edges end a basic-block. That way you'd have the
edges pre-split.
Richard.
[Bug c/54355] ICE on invalid code in switch statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54355 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.0
[Bug middle-end/53695] [4.8 Regression] ICE: in dfs_enumerate_from, at cfganal.c:1221 with -O2 -ftracer and labels/gotos
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
--- Comment #21 from rguenther at suse dot de rguenther at suse dot de
2012-08-23 11:22:19 UTC ---
On Thu, 23 Aug 2012, rguenther at suse dot de wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53695
Btw, another idea would be to make labels that are target of
abnormal edges end a basic-block. That way you'd have the
edges pre-split.
Like so, doesn't help this testcase but maybe the Fortran issues.
Richard.
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c(revision 190613)
+++ gcc/tree-cfg.c(working copy)
@@ -670,6 +674,10 @@ make_edges (void)
}
break;
+case GIMPLE_LABEL:
+ fallthru = true;
+ break;
+
default:
gcc_assert (!stmt_ends_bb_p (last));
fallthru = true;
@@ -2440,7 +2527,9 @@ stmt_starts_bb_p (gimple stmt, gimple pr
bool
stmt_ends_bb_p (gimple t)
{
- return is_ctrl_stmt (t) || is_ctrl_altering_stmt (t);
+ return (is_ctrl_stmt (t) || is_ctrl_altering_stmt (t)
+ || (gimple_code (t) == GIMPLE_LABEL
+ FORCED_LABEL (gimple_label_label (t;
}
/* Remove block annotations and other data structures. */
Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c(revision 190613)
+++ gcc/tree-cfgcleanup.c(working copy)
@@ -300,7 +300,8 @@ tree_forwarder_block_p (basic_block bb,
switch (gimple_code (stmt))
{
case GIMPLE_LABEL:
- if (DECL_NONLOCAL (gimple_label_label (stmt)))
+ if (DECL_NONLOCAL (gimple_label_label (stmt))
+ || FORCED_LABEL (gimple_label_label (stmt)))
return false;
if (optimize == 0 gimple_location (stmt) != locus)
return false;
[Bug c/54355] ICE on invalid code in switch statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54355 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-08-23 AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-23 11:24:36 UTC --- Created attachment 28068 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28068 gcc48-pr54355.patch Untested fix. While for the nested case c_push_function_context/c_pop_function_context around start_function restores the globals on failure, for the !nested case which includes extern fn decls (or suspected extern fn decls) nothing restores them.
[Bug c/54356] New: ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54356 Bug #: 54356 Summary: ICE in output_pic_addr_const Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: alexander.a...@informatik.tu-chemnitz.de Created attachment 28069 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28069 File demonstrating the bug. In the attachment is a very stripped down version of the code that makes gcc ICE. I tested with version: 4.1.2.20070115 (prerelease) on SuSE Linux 32 bit 4.7.1 on Debian (4.7.1-2) 64 bit with -m32-Flag The command line used to compile the code was: gcc -O1 -fPIC -c -m32 -o test.o asm_p_flag_ice.c This is a very minimalistic example. It works fine if we use the function address as argument. It works with other modifiers for the assembler. It works if -fPIC is ommitted or -O0 is used. I give here the options that were used to build the gcc bit on Debian: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.1 (Debian 4.7.1-2) $ uname -a Linux dimensio0 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux The output, if the file is compiled: $ gcc -O1 -fPIC -c -m32 -o test.o asm_p_flag_ice.c asm_p_flag_ice.c: In function ‘ICE_func’: asm_p_flag_ice.c:15:1: internal compiler error: in output_pic_addr_const, at config/i386/i386.c:13099 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Preprocessed source stored into /tmp/ccLvrTP3.out file, please attach this to your bugreport.
[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590
--- Comment #31 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-23
11:41:50 UTC ---
Btw, I have experimented with
Index: tree-into-ssa.c
===
--- tree-into-ssa.c (revision 190594)
+++ tree-into-ssa.c (working copy)
@@ -3224,11 +3224,35 @@ update_ssa (unsigned update_flags)
bitmap_head *dfs;
/* If the caller requested PHI nodes to be added, compute
-dominance frontiers. */
+dominance frontiers for all interesting blocks
+up to the dominating start_bb. */
dfs = XNEWVEC (bitmap_head, last_basic_block);
FOR_EACH_BB (bb)
bitmap_initialize (dfs[bb-index], bitmap_default_obstack);
- compute_dominance_frontiers (dfs);
+ EXECUTE_IF_SET_IN_BITMAP (blocks_to_update, 0, i, bi)
+ {
+ basic_block b = BASIC_BLOCK (i);
+ edge_iterator ei;
+ edge p;
+ if (EDGE_COUNT (b-preds) = 2)
+ FOR_EACH_EDGE (p, ei, b-preds)
+ {
+ basic_block runner = p-src;
+ basic_block domsb;
+ if (runner == start_bb)
+ continue;
+
+ domsb = get_immediate_dominator (CDI_DOMINATORS, b);
+ while (runner != domsb)
+ {
+ if (!bitmap_set_bit (dfs[runner-index],
+b-index))
+ break;
+ runner = get_immediate_dominator (CDI_DOMINATORS,
+ runner);
+ }
+ }
+ }
if (sbitmap_first_set_bit (old_ssa_names) = 0)
{
which helps reducing the time spent in computing dominance frontiers. But
as we no longer have bitmaps but bitmap_heads in dfs it's hard to verify
we only ever access dfs for entries we computed ... but we should,
looking at how compute_idf works(?).
[Bug c/54357] New: ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54357 Bug #: 54357 Summary: ICE in output_pic_addr_const Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: alexander.a...@informatik.tu-chemnitz.de Created attachment 28070 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28070 File demonstrating the bug. In the attachment is a very stripped down version of the code that makes gcc ICE. I tested with version: 4.1.2.20070115 (prerelease) on SuSE Linux 32 bit 4.7.1 on Debian (4.7.1-2) 64 bit with -m32-Flag The command line used to compile the code was: gcc -O1 -fPIC -c -m32 -o test.o asm_p_flag_ice.c This is a very minimalistic example. It works fine if we use the function address as argument. It works with other modifiers for the assembler. It works if -fPIC is ommitted or -O0 is used. I give here the options that were used to build the gcc bit on Debian: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.1 (Debian 4.7.1-2) $ uname -a Linux dimensio0 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux The output, if the file is compiled: $ gcc -O1 -fPIC -c -m32 -o test.o asm_p_flag_ice.c asm_p_flag_ice.c: In function ‘ICE_func’: asm_p_flag_ice.c:15:1: internal compiler error: in output_pic_addr_const, at config/i386/i386.c:13099 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Preprocessed source stored into /tmp/ccLvrTP3.out file, please attach this to your bugreport.
[Bug c/54357] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54357 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-23 11:44:48 UTC --- . *** This bug has been marked as a duplicate of bug 54356 ***
[Bug c/54358] New: ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54358 Bug #: 54358 Summary: ICE in output_pic_addr_const Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: alexander.a...@informatik.tu-chemnitz.de Created attachment 28071 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28071 Output as mentioned in ICE output In the attachment is a very stripped down version of the code that makes gcc ICE. I tested with version: 4.1.2.20070115 (prerelease) on SuSE Linux 32 bit 4.7.1 on Debian (4.7.1-2) 64 bit with -m32-Flag The command line used to compile the code was: gcc -O1 -fPIC -c -m32 -o test.o asm_p_flag_ice.c This is a very minimalistic example. It works fine if we use the function address as argument. It works with other modifiers for the assembler. It works if -fPIC is ommitted or -O0 is used. I give here the options that were used to build the gcc bit on Debian: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.1-2' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.1 (Debian 4.7.1-2) $ uname -a Linux dimensio0 3.2.0-3-amd64 #1 SMP Mon Jul 23 02:45:17 UTC 2012 x86_64 GNU/Linux The output, if the file is compiled: $ gcc -O1 -fPIC -c -m32 -o test.o asm_p_flag_ice.c asm_p_flag_ice.c: In function ‘ICE_func’: asm_p_flag_ice.c:15:1: internal compiler error: in output_pic_addr_const, at config/i386/i386.c:13099 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions. Preprocessed source stored into /tmp/ccLvrTP3.out file, please attach this to your bugreport.
[Bug c/54356] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54356 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-23 11:44:48 UTC --- *** Bug 54357 has been marked as a duplicate of this bug. ***
[Bug c/54358] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54358 --- Comment #1 from Alexander Adam alexander.adam at informatik dot tu-chemnitz.de 2012-08-23 11:46:18 UTC --- Created attachment 28072 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28072 original source file with comments
[Bug c/54356] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54356 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-23 11:47:46 UTC --- . *** This bug has been marked as a duplicate of bug 54358 ***
[Bug c/54358] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54358 --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-23 11:47:46 UTC --- *** Bug 54356 has been marked as a duplicate of this bug. ***
[Bug target/54358] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54358
--- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2012-08-23
11:54:12 UTC ---
Btw, I think this is invalid asm:
int ICE_func ( void)
{
void *returnaddr = retaddr;/* need the label address, works with
* function address
*/
__asm__(mov%0,(%%esp)\n
: /* no outputs */
: p (returnaddr)/* ICE only with p. r and g are working
*/
: /* none modified */
);
retaddr:
return 0;
}
'p' is not a correct constraint for mov.
[Bug c/54355] ICE on invalid code in switch statement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54355 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #28068|0 |1 is obsolete|| --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-23 11:56:51 UTC --- Created attachment 28073 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28073 gcc48-pr54355.patch Actually, it seems the comments added in PR29062 disagree with what is actually passed, two arguments are swapped. Dunno about the best empty_ok value in that case, but certainly nested should be true, we are definitely inside of a function already.
[Bug c++/18747] template int i; accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18747 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED CC|gcc-bugs at gcc dot gnu.org | AssignedTo|unassigned at gcc dot |paolo.carlini at oracle dot |gnu.org |com --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-23 13:06:51 UTC --- Looking into it.
[Bug target/54358] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54358 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-23 13:29:49 UTC --- Yes, definitely invalid. With PIC p is not correct constraint for any code label, address of a variable etc., all that requires adding some offset to the PIC register, therefore must allow register in the constraint.
[Bug driver/54335] -dm doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54335 --- Comment #3 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org 2012-08-23 13:37:16 UTC --- Author: hjl Date: Thu Aug 23 13:37:11 2012 New Revision: 190621 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=190621 Log: Add -da and remove -dm in GCC manual PR driver/54335 * doc/invoke.texi: Add -da and remove -dm. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug c++/54359] New: [C++0x][N3282] decltype in member function's trailing return type when defined outside of class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54359
Bug #: 54359
Summary: [C++0x][N3282] decltype in member function's trailing
return type when defined outside of class
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bruno-...@defraine.net
Even after closing bug #49003, there remain problems regarding the handling of
N3282 (resolution of DR 1207). Specifically, the problems have to do with a
definition of a member function outside of the class.
Consider these test cases:
int ref(int x) { return x; }
const int ref(const int x) { return x; }
class A {
int x;
int f() const;
auto test1() const - decltype(this);
auto test2() const - decltype(ref(x));
auto test3() const - decltype(f());
};
auto A::test1() const - decltype(this) {
return this;
}
auto A::test2() const - decltype(ref(x)) {
return ref(x);
}
auto A::test3() const - decltype(f()) {
return f();
}
This gives the following compiler errors in the C++0x mode of gcc 4.7.1:
- test1(): invalid use of 'this' at top level
- test2(): prototype for 'int A::test2() const' does not match any in class
'A' (candidate is: const int A::test2() const); additionally, 'int A::x' is
private
- test3(): cannot call member function 'int A::f() const' without object;
additionally, 'int A::f() const' is private
In summary, in the trailing return type of a const member function definition
outside of a class declaration, it seems:
1. I cannot explicitly reference 'this'
2. I can reference data members, but not private ones, and they are not const
3. I cannot invoke member functions
I believe all three function definitions should compile. Similarly, inline
definitions of the same member functions have no such problems:
class B {
int x;
int f() const;
auto test1() const - decltype(this) { return this; }
auto test2() const - decltype(ref(x)) { return ref(x); }
auto test3() const - decltype(f()) { return f(); }
};
It seems that issue #2 is a regression compared to gcc 4.6, which seemed to
allow some access to data members. Consider test4():
templatetypename X
class C {
const X x;
auto test4() const - decltype(x);
};
templatetypename X
auto CX::test4() const - decltype(x) {
return x;
}
This test compiles without problems under gcc 4.6.3. Whereas gcc 4.7.1 gives:
prototype for 'decltype (((CX*)0)-CX::x) CX::test4() const' does not
match any in class 'CX' (candidate is: decltype (((const
CX*)this)-CX::x) CX::test4() const)
[Bug tree-optimization/46590] [4.6/4.7/4.8 Regression] long compile time with -O2 and many loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #32 from Steven Bosscher steven at gcc dot gnu.org 2012-08-23 13:44:53 UTC --- (In reply to comment #31) which helps reducing the time spent in computing dominance frontiers. But as we no longer have bitmaps but bitmap_heads in dfs it's hard to verify we only ever access dfs for entries we computed ... but we should, looking at how compute_idf works(?). I don't understand this comment. You can still always do: bitmap_empty_p (dfs[bb-index]) to see if something was computed for bb.
[Bug target/54358] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54358 --- Comment #5 from Alexander Adam alexander.adam at informatik dot tu-chemnitz.de 2012-08-23 13:49:19 UTC --- (In reply to comment #4) Yes, definitely invalid. With PIC p is not correct constraint for any code label, address of a variable etc., all that requires adding some offset to the PIC register, therefore must allow register in the constraint. But shouldn't the ICE be replaced by something like do not use p constraint with -fPIC Instead of encouraging bug reports?
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 --- Comment #9 from H.J. Lu hjl.tools at gmail dot com 2012-08-23 13:58:15 UTC --- (In reply to comment #4) I believe that OImode is currently handled inconsistently in the compiler, and should be handled exactly in the way TImode is handled for xmm registers. There are some examples: -function_pass_avx256_p: OImode is handled together with VALID_AVX256_REG_MODE in parallels, but not in registers. -construct_container: OImode is created for container member -ix86_hard_regno_mode_ok: OImode is handled together with VALID_AVX256_REG_MODE. It is done on purpose. GCC needs an integer mode which is as wide as vector size for internal usage. I think that OImode should be a member of VALID_AVX256_REG_MODE. If we want to do that, we need first to update psABI to specify how to pass and return OImode.
[Bug target/54358] ICE in output_pic_addr_const
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54358 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-23 14:10:30 UTC --- If inline-asm is not involved, sure. But inline asm is a low level interface, where it is user responsibility to supply correct constraints, we have some quick measures, like a segfault handler if compiler segfaults during outputting of an inline asm pattern, we emit an error instead of ICE, but that doesn't handle assertion failures/aborts. There are simply way too many things with inline asm you can shoot yourself. The gcc documentation says that p constraint must be accompanied with address_operand check, which inline asm can't provide, so the p constraint is probably never suitable for inline asm.
[Bug rtl-optimization/42612] post-increment addressing not used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42612 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org Known to fail|| --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-23 14:15:47 UTC --- I haven't checked this on ARM but on SH there's a similar problem. See PR 50749. As far as I understand it, it is a problem of the auto-inc-dec pass, which is unable to find related addresses due to prior optimizations
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749 Oleg Endo olegendo at gcc dot gnu.org changed: What|Removed |Added CC||olegendo at gcc dot gnu.org Component|middle-end |rtl-optimization --- Comment #13 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-23 14:17:29 UTC --- PR 42612 describes a similar problem on ARM.
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342 --- Comment #10 from H.J. Lu hjl.tools at gmail dot com 2012-08-23 14:26:53 UTC --- There are /* We implement the move patterns for all vector modes into and out of SSE registers, even when no operation instructions are available. OImode move is available only when AVX is enabled. */ return ((TARGET_AVX mode == OImode) || VALID_AVX256_REG_MODE (mode) to deal with OImode and AVX. Please find out what you need to do to support vzeroupper insertion.
[Bug target/54087] __atomic_fetch_add does not use xadd instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087 Andrew Macleod amacleod at redhat dot com changed: What|Removed |Added Attachment #27927|0 |1 is obsolete|| Status|UNCONFIRMED |NEW Last reconfirmed||2012-08-23 AssignedTo|unassigned at gcc dot |amacleod at redhat dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #7 from Andrew Macleod amacleod at redhat dot com 2012-08-23 14:33:01 UTC --- Created attachment 28074 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28074 Generic expansion patch proposal This patch changes the tree-rtl expansion code to try using the complementary atomic add or sub operation with a negative operand if an instruction sequence is not created. This will enable the optimization automatically for all targets. Check to see if it solves the problem as well.
[Bug c/54360] New: missed optimalization: unnecessary indirect call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54360
Bug #: 54360
Summary: missed optimalization: unnecessary indirect call
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nel...@seznam.cz
Consider following program:
void bar(int *x);
int x(){
struct {
void (*b)(int *);
int a;
} foo;
foo.b=bar;
foo.b((foo.a));
foo.b((foo.a));
}
int y(){
void (*b)(int *);
int a;
b=bar;
b(a);
b(a);
}
In function x gcc eliminaties first indirect call but not second. In y both
calls are eliminated.
.file s.c
.text
.p2align 4,,15
.globl x
.type x, @function
x:
.LFB0:
.cfi_startproc
subq $24, %rsp
.cfi_def_cfa_offset 32
leaq 8(%rsp), %rdi
movq $bar, (%rsp)
call bar
leaq 8(%rsp), %rdi
call *(%rsp)
addq $24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size x, .-x
.p2align 4,,15
.globl y
.type y, @function
y:
.LFB1:
.cfi_startproc
subq $24, %rsp
.cfi_def_cfa_offset 32
leaq 12(%rsp), %rdi
call bar
leaq 12(%rsp), %rdi
call bar
addq $24, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size y, .-y
.ident GCC: (Debian 20120820-1) 4.8.0 20120820 (experimental) [trunk
revision 190537]
.section .note.GNU-stack,,@progbits
[Bug c/54360] missed optimalization: unnecessary indirect call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54360
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-23
15:00:25 UTC ---
That is because bar could do:
#include stddef.h
void baz (int *);
void bar (int *x)
{
struct S { void (*b) (int *); int a; } *p;
p = (struct S) ((char *) x - offsetof (struct S, a));
p-b = baz;
}
It can't do something similar in case of y.
[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-23 15:26:07 UTC --- (In reply to comment #7) This is fixed on trunk and 4.7.1 Where's the patch that fixed it on the 4.7 branch?
[Bug target/54087] __atomic_fetch_add does not use xadd instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54087 --- Comment #8 from Ulrich Drepper drepper.fsp at gmail dot com 2012-08-23 15:41:49 UTC --- (In reply to comment #7) Check to see if it solves the problem as well. I tested it. Seems to work in all cases and does not disturb other optimizations like comparisons with zero.
[Bug bootstrap/50461] mpfr.h found in mpfr-3.1.0/src instead of mpfr-3.0.1/. as previously
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50461 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.8.0 Known to fail||4.7.1 --- Comment #9 from Jonathan Wakely redi at gcc dot gnu.org 2012-08-23 15:43:48 UTC --- For the record this is not fixed for 4.7.1, and from looking at the sources doesn't appear to be fixed in the 4.7 branch at all. http://gcc.gnu.org/viewcvs/trunk/configure?r1=187341r2=187340pathrev=187341 applies cleanly to the 4.7.1 release and fixes the problem.
[Bug target/54349] _mm_cvtsi128_si64 unnecessary stores value at stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54349
Ondrej Bilka neleai at seznam dot cz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #2 from Ondrej Bilka neleai at seznam dot cz 2012-08-23 15:45:54
UTC ---
(In reply to comment #1)
Not a bug. You need to tune for a CPU where inter-unit moves are desirable.
The default is generic tuning, which is a compromise between Intel CPUs (where
they are desirable) and AMD CPUs (where they are undesirable). In this
particular case the generic tuning doesn't do inter-unit moves as part of the
compromise. If you -mtune=corei7 or similar, you'll get an inter-unit move in
both cases.
What amd procesors?
Compile following two files with march=core2 and march=amdfam10. Amd version
was always at least 5% slower.
Tested on AMD Athlon(tm) 64 Processor 3200+,AMD Opteron(tm) Processor 6134
AMD FX(tm)-8150 Eight-Core Processor, AMD Phenom(tm) II X6 1090T Processor
#include emmintrin.h
#include stdint.h
int64_t foo(int64_t a,int64_t c){__m128i b=
_mm_cvtsi64_si128(a),d=_mm_cvtsi64_si128(c);
return _mm_cvtsi128_si64(_mm_add_epi8(b,d));
}
/*need split otherwise simplified to identical code*/
#include emmintrin.h
#include stdint.h
int main(){
int i;
int64_t x=0;
for (i=0;i1;i++) x=foo(x,1);
return x;
}
[Bug c/54149] write introduction incorrect wrt the C11 memory model
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54149
--- Comment #1 from Francesco Zappa Nardelli francesco.zappa.nardelli at gmail
dot com 2012-08-23 16:34:38 UTC ---
Here is another C program that hits a similar write-introduction problem:
int g_7, g_372;
char func_10 () {
for (; g_7 0; ++g_7) {
}
return 0;
}
void main () {
int l_8;
lbl_914:
(l_8 = g_7) = func_10 ();
if (l_8)
if (g_372) {
} else
goto lbl_914;
}
The reference trace is:
*** unoptimised trace: gcc --param allow-store-data-races=0 8-min.c -o
8-min_unopt
g_70 4Init
g_3720 4Init
g_70 4Load
g_70 4Load
while the optimised trace (requires -O2 or -O3 to be observable) is
*** optimised trace: gcc --param allow-store-data-races=0 -O3 8-min.c -o
8-min_opt
g_70 4Init
g_3720 4Init
g_3720 4Load
g_70 4Load
g_70 4 Store
[ gcc version 4.8.0 20120627 (experimental) (GCC) ]
[Bug rtl-optimization/54342] [4.8 Regression] Wrong mode of call argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54342
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #11 from H.J. Lu hjl.tools at gmail dot com 2012-08-23 17:16:21
UTC ---
(In reply to comment #8)
I don't think AVX supports true 256-bit integer. On the other hand, I was
also puzzled by compute_record_mode, which excludes UNION_TYPE and
QUAL_UNION_TYPE. Will including them break union?
It breaks gcc.c-torture/compile/pr42196-2.c:
union U
{
__complex__ int ci;
__complex__ float cf;
};
float gd;
extern float bar (union U);
float foo (int b, double f1, double f2, int c1, int c2)
{
union U u;
double r;
if (b)
{
__real__ u.cf = f1;
__imag__ u.cf = f2;
}
else
{
__real__ u.ci = c1;
__imag__ u.ci = c2;
}
r = bar (u);
return r;
}
The proper fix is to allow OImode in your case without adding it to
VALID_AVX256_REG_MODE.
[Bug middle-end/53676] [4.7 regression] empty loop is not always removed now
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53676 --- Comment #16 from Matt Hargett matt at use dot net 2012-08-23 18:01:08 UTC --- Back/forward-porting of the trivial restoration of the old behavior is acceptable to me, as it would remove a major barrier to our adoption of 4.7.x. That being said, if there's multi-platform testing I can do with a 'better' fix based on trunk, I have SPARC and ARM qemu environments set up to regression test on. BTW, I realized that my initial analysis was wrong -- the int32_t and uint32_t benchmarks are unaffected by this regression. Let me know if there's an easy way to apply the restoration patch and I'll test it locally on our amdfam10 and bdver2 hardware. If the testcase committed to trunk would be applicable to a 4.7 fix as well, I can make a patch to integrate that to ensure thie functionality doesn't regress again in future 4.7.x point releases. I'm happy to do as much footwork as my expertise allows, just let me know :) Thanks!
[Bug target/47440] Use LCM for vzeroupper insertion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47440 --- Comment #4 from Vladimir Yakovlev vbyakovl23 at gmail dot com 2012-08-23 19:15:58 UTC --- As recomended Uros, I splitted up the patch by two part. First, middle end part is here http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01590.html
[Bug tree-optimization/54317] [4.8 Regression] FAIL: c45532m c45532n c45532o c45532p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54317 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2012-08-23 22:07:47 UTC --- Fixed by change!
[Bug target/54065] [SH] Prefer @(R0,Rn) addressing for floating-point load/store
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54065
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-23 23:09:07
UTC ---
On rev 190580 I've tried out replacing the sh_legitimize_address function with
the following one:
sh_legitimize_address (rtx x, rtx oldx, enum machine_mode mode)
{
if (flag_pic)
x = legitimize_pic_address (oldx, mode, NULL_RTX);
if (TARGET_SHMEDIA)
return x;
if (GET_CODE (x) == PLUS CONST_INT_P (XEXP (x, 1))
BASE_REGISTER_RTX_P (XEXP (x, 0)))
{
/* SH2A has displacement floating-point loads and stores.
On everything else change the address to use index addressing. */
if (FLOAT_MODE_P (mode) TARGET_FPU_ANY ! TARGET_SH2A)
{
rtx reg = gen_reg_rtx (Pmode);
emit_insn (gen_move_insn (reg, XEXP (x, 1)));
return gen_rtx_PLUS (Pmode, reg, XEXP (x, 0));
}
struct disp_adjust adj = sh_find_mov_disp_adjust (mode,
INTVAL (XEXP (x, 1)));
if (adj.offset_adjust != NULL_RTX adj.mov_disp != NULL_RTX)
{
rtx sum = expand_binop (Pmode, add_optab, XEXP (x, 0),
adj.offset_adjust, NULL_RTX, 0,
OPTAB_LIB_WIDEN);
return gen_rtx_PLUS (Pmode, sum, adj.mov_disp);
}
}
return x;
}
This 'fixes' the issue mentioned in the description. Looking at CSiBE
result-size there is a small overall improvement, but there are also quite some
code size increases. It seems difficult to select the optimal addressing mode
for these kind of situations without looking at the surrounding code.
It also seems that transforming every displacement address into an index
address will make it difficult for the auto-inc-dec pass to find
opportunities, as it is not smart enough to undo the indexed address
transformation. Last but not least, the indexed address increases pressure on
R0 of course.
[Bug target/53911] [SH] Improve displacement addressing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53911 --- Comment #2 from Oleg Endo olegendo at gcc dot gnu.org 2012-08-23 23:11:21 UTC --- A related paper from 2004: http://www.netgull.com/gcc/summit/2004/Addressing%20Mode%20Selection.pdf
[Bug c++/54361] New: Compiling for c++11 gives a warning on scanf() with %as format specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54361 Bug #: 54361 Summary: Compiling for c++11 gives a warning on scanf() with %as format specifier Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: strik...@gmail.com Target: x86_64-unknown-linux-gnu Configured with: /home/utils/src/gcc-4.7.0/configure --prefix=/home/utils/gcc-4.7.0 --enable-languages=c,c++,objc,fortran --with-gmp=/home/utils/gmp-5.0.2-static --with-mpfr=/home/utils/mpfr-3.1.0-static --with-mpc=/home/utils/mpc-0.9-static --with-as=/home/utils/binutils-2.21.1/bin/as --with-ld=/home/utils/binutils-2.21.1/bin/ld Thread model: posix gcc version 4.7.0 (GCC) Source code attached as c.cpp $ g++ -std=c++11 -Wall -Werror c.cpp c.cpp: In function 'int main()': c.cpp:10:26: error: format '%a' expects argument of type 'float*', but argument 2 has type 'char**' [-Werror=format] c.cpp:7:7: error: unused variable 'a' [-Werror=unused-variable] cc1plus: all warnings being treated as errors
[Bug c++/54361] Compiling for c++11 gives a warning on scanf() with %as format specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54361 --- Comment #1 from Nick Strikos strikosn at gmail dot com 2012-08-23 23:35:31 UTC --- Created attachment 28075 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28075 Testcase
[Bug c++/54361] Compiling for c++11 gives a warning on scanf() with %as format specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54361 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2012-08-23 23:54:24 UTC --- The warning is correct, %as (the oldish GNU extension) clashes with ISO C99 a modifier for hex floats, if you want to allocate memory, use %ms instead, which is the standard way of doing the same.
[Bug c++/54361] Compiling for c++11 gives a warning on scanf() with %as format specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54361 strikosn at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from strikosn at gmail dot com 2012-08-24 00:04:39 UTC --- Right, %ms is standardized and solves the problem. But the whole thing is confusing because previously working C++ programs can no more compile with -std=c++11 or -std=gnu++11, and this has nothing to do with the C++11 standard.
[Bug c++/54359] [C++0x][N3282] decltype in member function's trailing return type when defined outside of class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54359 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2012-08-24 00:29:39 UTC --- I'm wondering if we shouldn't just have a metabug for decltype and one for lambdas... looking for volunteers (Daniel? ;)
[Bug middle-end/54362] New: COND_EXPR not understood by either alias or ITM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54362
Bug #: 54362
Summary: COND_EXPR not understood by either alias or ITM
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pins...@gcc.gnu.org
Take this slightly modified gcc.dg/tm/memopt-12.c :
/* { dg-do compile } */
/* { dg-options -fgnu-tm -O3 -fdump-tree-tmmark } */
extern int test(void) __attribute__((transaction_safe));
extern void *malloc (__SIZE_TYPE__) __attribute__((malloc,transaction_safe));
struct large { int foo[500]; };
int f(int j)
{
int *p1, *p2, *p3;
p1 = malloc (sizeof (*p1)*5000);
__transaction_atomic {
_Bool t;
int i = 1;
*p1 = 0;
p2 = malloc (sizeof (*p2)*6000);
*p2 = 1;
t = test();
for (i = 0;i j;i++)
{
/* p3 = PHI (p1, p2) */
if (t)
p3 = p1;
else
p3 = p2;
/* Since both p1 and p2 are thread-private, we can inherit the
logging already done. No ITM_W* instrumentation necessary. */
*p3 = 555;
}
}
return p3[something()];
}
/* { dg-final { scan-tree-dump-times ITM_WU 0 tmmark } } */
/* { dg-final { cleanup-tree-dump tmmark } } */
--- CUT ---
It currently fails because the aliasing code does not understand that p3 cannot
alias only local memory.
I found this while adding support to phiopt to convert some phi's into
COND_EXPR.
[Bug c/54363] New: ICE when compiling malformed struct initializers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54363
Bug #: 54363
Summary: ICE when compiling malformed struct initializers
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kamar...@gmail.com
Created attachment 28076
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28076
preprocessed source code with gcc 4.7.1
This bug is originally reported by Bernhard as
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684635
The following invalid code triggers an ICE with gcc-4.7
$cat t.c
struct bla{char **a;};void test(void){struct bla b = {.a =(char**){a,b}};}
$gcc -c t.c
t.c: In function ‘test’:
t.c:1:46: warning: initialization from incompatible pointer type [enabled by
default]
t.c:1:46: warning: (near initialization for ‘(anonymous)’) [enabled by default]
t.c:1:46: warning: excess elements in scalar initializer [enabled by default]
t.c:1:46: warning: (near initialization for ‘(anonymous)’) [enabled by default]
t.c:1:50: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See file:///usr/share/doc/gcc-4.7/README.Bugs for instructions.
Preprocessed source stored into /tmp/ccS0X8p2.out file, please attach this to
your bugreport.
Attaching the preprocessed source code as ccS0X8p2.out . I am using
$gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.1-2'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.1 (Debian 4.7.1-2)
The same ICE also occurs with gcc version 4.6.2 (Debian 4.6.2-12). But gcc
version 4.4.7 (Debian 4.4.7-1) compiles with a warning.
$gcc-4.4 -c t.c
t.c: In function ‘test’:
t.c:1: warning: initialization from incompatible pointer type
t.c:1: warning: excess elements in scalar initializer
t.c:1: warning: (near initialization for ‘(anonymous)’)
$gcc-4.4 -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.4.7-1'
--with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.4 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.4.7 (Debian 4.4.7-1)
