[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze

2008-11-16 Thread spark at gcc dot gnu dot org


--- Comment #10 from spark at gcc dot gnu dot org  2008-11-17 06:13 ---
I agree that the overeager has the worse worst-case bound. I'll happily approve
a patch that drops overeager and leave double-queuing only, provided we have
empirical data over some known programs to show that it is a compile time
neutral change (I bet it will be so, or worst case, only a very slight
slowdown). 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365



[Bug rtl-optimization/36365] [4.3/4.4 Regression] Hang in df_analyze

2008-05-30 Thread spark at gcc dot gnu dot org


--- Comment #4 from spark at gcc dot gnu dot org  2008-05-30 18:28 ---
I'm still building the compiler to reproduce the problem.
But can somebody try compiling with --param df-double-queue-threshold-factor=0
and see if it helps ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36365



[Bug c++/34949] Dead code in empty destructors.

2008-01-24 Thread spark at gcc dot gnu dot org


--- Comment #4 from spark at gcc dot gnu dot org  2008-01-24 18:16 ---
I don't think this can be implemented in the FE,
at least to be really effective.
The more common cases are not really empty destructor.
E.g. there's inlining involved:

class Foo
{
public:
  virtual ~Foo();
};

Foo::~Foo()
{
}


class Bar : public Foo
{
public:
  virtual ~Bar();
};

Bar::~Bar()
{
}


where Foo::~Foo() has to be inlined before we can determine
~Bar() is really empty.

But emptiness isn't really how we want to decide eliminating those
but rather the dependence on the vtable itself. e.g.:
extern C int printf(const char* s);

class Foo
{
public:
  virtual ~Foo();
};

Foo::~Foo()
{
  printf(good bye foo\n);
}


class Bar : public Foo
{
public:
  virtual ~Bar();
};

Bar::~Bar()
{
  printf(good bye bar\n);
}

In this case, there's no need for vtable update inside the destructor
(which is more common).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949



[Bug middle-end/34949] New: Dead code in trivial destructors.

2008-01-23 Thread spark at gcc dot gnu dot org
# cat dead.cpp
class Foo
{
public:
  virtual ~Foo();
};

Foo::~Foo()
{
}
# g++ -O2 -S dead.cpp
# cat dead.cpp
...
.globl _ZN3FooD2Ev
.type   _ZN3FooD2Ev, @function
_ZN3FooD2Ev:
.LFB3:
pushl   %ebp
.LCFI0: 
movl%esp, %ebp
.LCFI1: 
movl8(%ebp), %eax
movl$_ZTV3Foo+8, (%eax)
popl%ebp
ret
.LFE3:  
.size   _ZN3FooD2Ev, .-_ZN3FooD2Ev
...


In this trivial case (which is actually quite common),
there's no need for the store to update the vtable pointer,
since there's nothing to do in this destructor.


-- 
   Summary: Dead code in trivial destructors.
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949



[Bug c++/34949] Dead code in empty destructors.

2008-01-23 Thread spark at gcc dot gnu dot org


--- Comment #2 from spark at gcc dot gnu dot org  2008-01-23 23:23 ---
I understand why it's difficult to delete the code in the middle-end. But this
case seems to be quite common - not the empty body but more common cases are
destructors whose body doesn't need vtable.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949



[Bug middle-end/34400] [4.3 regression] bad interaction between DF and SJLJ exceptions

2008-01-17 Thread spark at gcc dot gnu dot org


--- Comment #49 from spark at gcc dot gnu dot org  2008-01-17 20:03 ---
Subject: Bug 34400

Author: spark
Date: Thu Jan 17 20:02:56 2008
New Revision: 131608

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131608
Log:
2008-01-17  Seongbae Park  [EMAIL PROTECTED]

PR rtl-optimization/34400
* df-core.c (df_worklist_dataflow_overeager,
df_worklist_dataflow_doublequeue): New functions.
(df_worklist_dataflow): Two different worklist solvers.
* params.def (PARAM_DF_DOUBLE_QUEUE_THRESHOLD_FACTOR):
New param.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-core.c
trunk/gcc/params.def


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34400



[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha

2007-11-30 Thread spark at gcc dot gnu dot org


--- Comment #18 from spark at gcc dot gnu dot org  2007-11-30 17:02 ---
Subject: Bug 34171

Author: spark
Date: Fri Nov 30 17:02:43 2007
New Revision: 130539

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=130539
Log:
gcc/testsuite/ChangeLog:

2007-11-30  Martin Michlmayr [EMAIL PROTECTED]

PR rtl-optimization/34171
* gcc.dg/pr34171.c: New testcase.

gcc/ChangeLog:

2007-11-30  Seongbae Park [EMAIL PROTECTED]

PR rtl-optimization/34171
* cfgrtl.c (update_bb_for_insn_chain): New function,
refactored from update_bb_for_insn.
(update_bb_for_insn): Call update_bb_for_insn.
(rtl_merge_blocks, try_redirect_by_replacing_jump):
Replace a loop with update_bb_for_insn_chain call.
(cfg_layout_merge_blocks): Add a call to
update_bb_for_insn_chain. Replace the for loop
with a call to update_bb_for_insn_chain.


Added:
trunk/gcc/testsuite/gcc.dg/pr34171.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgrtl.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171



[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha

2007-11-21 Thread spark at gcc dot gnu dot org


--- Comment #7 from spark at gcc dot gnu dot org  2007-11-21 16:22 ---
(In reply to comment #6)
 Subject: Re:  [4.3 Regression] Segfault in df_chain_remove_problem
  with -O3 on alpha
 
 So it means the basic block has been deleted.
 
 I want to see what happens if I consolidate all the 
 out_of_date_transfer_functions bitmaps into one.  Seongbae, do you 
 remember experimenting with anything like that?
 
 Paolo

Not really. 
I agree that it's most likely a bb being deleted though.
I guess somebody will have to trace through using a debugger 
I'll try to build a cross to alpha and see if I can reproduce the problem
today.


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
   |dot org |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171



[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha

2007-11-21 Thread spark at gcc dot gnu dot org


--- Comment #12 from spark at gcc dot gnu dot org  2007-11-21 20:40 ---
At the end of fwprop2 pass in fwprop_done(), we call cleanup_cfg()
and it merges a few blocks, making some bb disappear (in this particular case,
bb index 25), which clears the bit in df_chain-out_of_date_transfer_functions.
Then, somehow, some of the insns originating from 25 has their bb numbers not
reset, and later those insns get the new bb numbers assigned, at which point we
call df_insn_change_bb(), which sets the bit for the deleted block on
out_of_date_transfer_functions map.
Then after fwprop, TODO runs df_finish_pass and we bomb.

I'm working on a fix.


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Last reconfirmed|2007-11-21 17:47:04 |2007-11-21 20:40:45
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171



[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha

2007-11-21 Thread spark at gcc dot gnu dot org


--- Comment #13 from spark at gcc dot gnu dot org  2007-11-21 22:08 ---
The following patch seems to fix the problem:

diff -r fad6feb87420 gcc/cfgrtl.c
--- a/gcc/cfgrtl.c  Wed Nov 21 00:17:50 2007 +
+++ b/gcc/cfgrtl.c  Wed Nov 21 14:07:15 2007 -0800
@@ -2629,6 +2629,7 @@ cfg_layout_merge_blocks (basic_block a,
   /* In the case basic blocks are not adjacent, move them around.  */
   if (NEXT_INSN (BB_END (a)) != BB_HEAD (b))
 {
+  rtx insn;
   rtx first = unlink_insn_chain (BB_HEAD (b), BB_END (b));

   emit_insn_after_noloc (first, BB_END (a), a);
@@ -2637,7 +2638,15 @@ cfg_layout_merge_blocks (basic_block a,
first = NEXT_INSN (first);
   gcc_assert (NOTE_INSN_BASIC_BLOCK_P (first));
   BB_HEAD (b) = NULL;
+  insn = NEXT_INSN (first);
   delete_insn (first);
+
+  for (; insn != NEXT_INSN (BB_END (b));
+  insn = NEXT_INSN (insn))
+   {
+ set_block_for_insn (insn, a);
+ df_insn_change_bb (insn);
+   }
 }
   /* Otherwise just re-associate the instructions.  */
   else


I'm going to stare at the surrounding code a bit more 
to convince myself, and will do some testing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171



[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha

2007-11-21 Thread spark at gcc dot gnu dot org


--- Comment #15 from spark at gcc dot gnu dot org  2007-11-21 22:43 ---
(In reply to comment #14)
 The patch is semi-wrong.  The call to emit_insn_after_noloc() should already
 set the proper BLOCK_FOR_INSN for every insn.  Only doing the
 df_insn_change_bb() should be sufficient.

Thanks Steven. Something like:

diff -r fad6feb87420 gcc/cfgrtl.c
--- a/gcc/cfgrtl.c  Wed Nov 21 00:17:50 2007 +
+++ b/gcc/cfgrtl.c  Wed Nov 21 14:40:43 2007 -0800
@@ -2629,6 +2629,7 @@ cfg_layout_merge_blocks (basic_block a,
   /* In the case basic blocks are not adjacent, move them around.  */
   if (NEXT_INSN (BB_END (a)) != BB_HEAD (b))
 {
+  rtx insn;
   rtx first = unlink_insn_chain (BB_HEAD (b), BB_END (b));

   emit_insn_after_noloc (first, BB_END (a), a);
@@ -2637,6 +2638,14 @@ cfg_layout_merge_blocks (basic_block a,
first = NEXT_INSN (first);
   gcc_assert (NOTE_INSN_BASIC_BLOCK_P (first));
   BB_HEAD (b) = NULL;
+
+  /* emit_insn_after_noloc doesn't call df_insn_change_bb.
+ We need to explicitly call df_insn_change_bb here. */
+  for (insn = NEXT_INSN (first);
+  insn != NEXT_INSN (BB_END (b));
+  insn = NEXT_INSN (insn))
+   df_insn_change_bb (insn);
+
   delete_insn (first);
 }
   /* Otherwise just re-associate the instructions.  */


I see bunch of similar loops throughout cfgrtl.c.
I'll see if I should refactor those loops into separate functions 
(one with set_block_for_insn and one without).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171



[Bug rtl-optimization/34171] [4.3 Regression] Segfault in df_chain_remove_problem with -O3 on alpha

2007-11-21 Thread spark at gcc dot gnu dot org


--- Comment #16 from spark at gcc dot gnu dot org  2007-11-22 00:30 ---
I'm bootstrapping the following patch. This includes some slight refactoring of
set_block_for_insn/df_insn_change_bb loops within cfgrtl.c.
It's mostly cosmetic change on top of the patch on comment #15.

diff -r fad6feb87420 gcc/cfgrtl.c
--- a/gcc/cfgrtl.c  Wed Nov 21 00:17:50 2007 +
+++ b/gcc/cfgrtl.c  Wed Nov 21 23:48:55 2007 +
@@ -465,23 +465,48 @@ emit_insn_at_entry (rtx insn)
   commit_edge_insertions ();
 }

-/* Update insns block within BB.  */
+/* Update BLOCK_FOR_INSN of insns between BEGIN and END
+   including BEGIN but not END, and notify df of the change.
+   Note that NEXT_INSN (END) has to have a valid value
+   (either NULL or a pointer to a valid insn). */
+
+static void
+update_bb_for_insns (rtx begin, rtx end, basic_block bb)
+{
+  rtx insn;
+
+  for (insn = begin; insn != end; insn = NEXT_INSN (insn))
+{
+  if (!BARRIER_P (insn))
+   {
+ set_block_for_insn (insn, bb);
+ df_insn_change_bb (insn);
+   }
+}
+}
+
+/* Call df_insn_change_bb for insns between BEGIN and END
+   including BEGIN but not END.
+   Note that NEXT_INSN (END) has to have a valid value
+   (either NULL or a pointer to a valid insn). */
+
+static void
+notify_bb_change_for_insns (rtx begin, rtx end)
+{
+  rtx insn;
+
+  for (insn = begin; insn != end; insn = NEXT_INSN (insn))
+if (!BARRIER_P (insn))
+  df_insn_change_bb (insn);
+}
+
+/* Update BLOCK_FOR_INSN of insns in BB to BB,
+   and notify df of the change.  */

 void
 update_bb_for_insn (basic_block bb)
 {
-  rtx insn;
-
-  for (insn = BB_HEAD (bb); ; insn = NEXT_INSN (insn))
-{
-  if (!BARRIER_P (insn))
-   {
- set_block_for_insn (insn, bb);
- df_insn_change_bb (insn);
-   }
-  if (insn == BB_END (bb))
-   break;
-}
+  update_bb_for_insns (BB_HEAD (bb), NEXT_INSN (BB_END (bb)), bb);
 }


 /* Return the INSN immediately following the NOTE_INSN_BASIC_BLOCK
@@ -629,16 +654,7 @@ rtl_merge_blocks (basic_block a, basic_b
   /* Reassociate the insns of B with A.  */
   if (!b_empty)
 {
-  rtx x;
-
-  for (x = a_end; x != b_end; x = NEXT_INSN (x))
-   {
- set_block_for_insn (x, a);
- df_insn_change_bb (x);
-   }
-
-  set_block_for_insn (b_end, a);
-  df_insn_change_bb (b_end);
+  update_bb_for_insns (a_end, NEXT_INSN (b_end), a);

   a_end = b_end;
 }
@@ -843,14 +859,9 @@ try_redirect_by_replacing_jump (edge e,
 which originally were or were created before jump table are
 inside the basic block.  */
  rtx new_insn = BB_END (src);
- rtx tmp;
-
- for (tmp = NEXT_INSN (BB_END (src)); tmp != barrier;
-  tmp = NEXT_INSN (tmp))
-   {
- set_block_for_insn (tmp, src);
- df_insn_change_bb (tmp);
-   }
+
+ update_bb_for_insns (NEXT_INSN (BB_END (src)),
+  barrier, src);

  NEXT_INSN (PREV_INSN (new_insn)) = NEXT_INSN (new_insn);
  PREV_INSN (NEXT_INSN (new_insn)) = PREV_INSN (new_insn);
@@ -2637,6 +2648,12 @@ cfg_layout_merge_blocks (basic_block a,
first = NEXT_INSN (first);
   gcc_assert (NOTE_INSN_BASIC_BLOCK_P (first));
   BB_HEAD (b) = NULL;
+
+  /* emit_insn_after_noloc doesn't call df_insn_change_bb.
+ We need to explicitly notify. */
+  notify_bb_change_for_insns (NEXT_INSN (first),
+ NEXT_INSN (BB_END (b)));
+
   delete_insn (first);
 }
   /* Otherwise just re-associate the instructions.  */
@@ -2644,13 +2661,8 @@ cfg_layout_merge_blocks (basic_block a,
 {
   rtx insn;

-  for (insn = BB_HEAD (b);
-  insn != NEXT_INSN (BB_END (b));
-  insn = NEXT_INSN (insn))
-   {
- set_block_for_insn (insn, a);
- df_insn_change_bb (insn);
-   }
+  update_bb_for_insns (BB_HEAD (b),
+   NEXT_INSN (BB_END (b)), a);

   insn = BB_HEAD (b);
   /* Skip possible DELETED_LABEL insn.  */


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34171



[Bug middle-end/33662] [4.3 Regression] Wrong register allocation on SH

2007-10-10 Thread spark at gcc dot gnu dot org


--- Comment #5 from spark at gcc dot gnu dot org  2007-10-11 00:51 ---
What configure option should I use to enable -m1 option support ?
Looks like plain-vanilla configured sh4-elf compiler doesn't support -m1 flag.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33662



[Bug rtl-optimization/33224] failing rtl iv analysis (maybe due to df)

2007-08-29 Thread spark at gcc dot gnu dot org


--- Comment #2 from spark at gcc dot gnu dot org  2007-08-29 15:23 ---
I suspect this might be due to not updating the rd information after unrolling.
Can you check if 
analyze_insns_in_loop() (which calls df_analyze()) is being called just before
the problematic unrolling ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224



[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame

2007-07-05 Thread spark at gcc dot gnu dot org


--- Comment #24 from spark at gcc dot gnu dot org  2007-07-05 23:44 ---
Subject: Bug 32475

Author: spark
Date: Thu Jul  5 23:44:44 2007
New Revision: 126391

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126391
Log:
2007-07-05  Seongbae Park  [EMAIL PROTECTED]

PR rtl-optimization/32475
* df-scan.c (df_def_record_1): Add a use of the stack pointer
for every definition of the stack pointer.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-scan.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475



[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame

2007-07-03 Thread spark at gcc dot gnu dot org


--- Comment #23 from spark at gcc dot gnu dot org  2007-07-03 19:41 ---
This patch:

diff -r 29a7055e69fc gcc/df-scan.c
--- a/gcc/df-scan.c Sun Jun 24 00:16:55 2007 +
+++ b/gcc/df-scan.c Tue Jul 03 12:38:41 2007 -0700
@@ -2763,6 +2763,12 @@ df_def_record_1 (struct df_collection_re
   || (GET_CODE (dst) == SUBREG  REG_P (SUBREG_REG (dst
 df_ref_record (collection_rec,
dst, loc, bb, insn, DF_REF_REG_DEF, flags);
+
+  /* We want to keep sp alive everywhere - by making all
+ writes to sp also use of sp. */
+  if (REG_P (dst)  REGNO (dst) == STACK_POINTER_REGNUM)
+df_ref_record (collection_rec,
+   dst, NULL, bb, insn, DF_REF_REG_USE, flags);
 }


also fixes the problem, by treating all defs of SP as a use of SP.
This patch essentially makes SP alive everywhere.
Also, this would create less number of unnecessary df_ref's
(since presumably there are less number of stack defs than
MEM_LOAD/STORE w/ hard frame pointer reference).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475



[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame

2007-07-02 Thread spark at gcc dot gnu dot org


--- Comment #20 from spark at gcc dot gnu dot org  2007-07-02 06:56 ---
We already put stack pointer in the exit block use set always.
However, after epilogue is generated, we see the sp restoration code:


1 NOTE_INSN_DELETED
4 NOTE_INSN_BASIC_BLOCK
   22 [--sp:SI]=bp:SI
   23 bp:SI=sp:SI
   24 {sp:SI=sp:SI-0x10;clobber flags:CC;clobber [scratch];}
   25 NOTE_INSN_PROLOGUE_END
3 NOTE_INSN_FUNCTION_BEG
   19 ax:SI=[bp:SI+0x8]
  REG_EQUIV: [bp:SI+0x8]
6 [bp:SI-0x4]=ax:SI
   21 dx:SI=bp:SI-0x4
   18 ax:SI=0x5a
  REG_EQUIV: 0x5a
9 {ax:SI=asm_operands;clobber fpsr:QI;clobber flags:QI;clobber [scratch];}
   26 NOTE_INSN_EPILOGUE_BEG
   27 {sp:SI=bp:SI+0x4;bp:SI=[bp:SI];clobber [scratch];}
   28 return
i  29: barrier
   20 NOTE_INSN_DELETED

Insn 27, which restores the sp for the caller, naturally writes to %sp,
and this makes %sp dead at insn 24.
I think the only correct solution is somehow to mark sp as used by insn 27,
or some similar effect. So, although this is a scanning problem, 
we may want to consider adding a use of %sp inside 27 or just before insn 27,
*if* sp is indeed necessary. It is not possible for df to figure this out
alone, as its epilogue generation code that determines whether we want sp or
not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475



[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame

2007-07-02 Thread spark at gcc dot gnu dot org


--- Comment #22 from spark at gcc dot gnu dot org  2007-07-02 17:33 ---
(In reply to comment #21)

I don't think this patch is quite enough.
IIUC, it is still possible (although very unlikely) for stack space to be
required without any MEM_LOAD or MEM_STORE present, and without any direct
reference to sp. Even if such a case is not possible,
we still want to avoid sp looking as if dead for any point at function
that it shouldn't be - 
as I pointed out earlier, after epilogue generation, because of the sp
restoration, sp looks as if it's dead. 
This can cause a problem, e.g. if we implement any hard register renaming pass
after register alloc/reload - because from df's point of view, %sp will look
available between the last MEM_LOAD/MEM_STORE w/ hard fp reference, and the sp
restoration code in the epilogue.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475



[Bug target/32552] New: Runtime failure in SPEC CPU2000 benchmark fma3d and applu

2007-06-29 Thread spark at gcc dot gnu dot org
SPEC CPU2000 applu and fma3d fail at runtime when compiled with -O3.


-- 
   Summary: Runtime failure in SPEC CPU2000 benchmark fma3d and
applu
   Product: gcc
   Version: 4.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: spark at gcc dot gnu dot org
  GCC host triplet: ia64-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552



[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu

2007-06-29 Thread spark at gcc dot gnu dot org


--- Comment #1 from spark at gcc dot gnu dot org  2007-06-29 21:41 ---
Below is the email I sent to Jim Wilson asking for help
with the analysis of the bug.


Hi Jim,

This is an analysis of a correctness bug on ia64,
which root cause has to do with your code.

After dataflow merge, Richard Guenther reported
two runtime failures in SPEC CPU2000 programs on ia64.
It turned out to be related to the following code you wrote
(or at least committed, according to svn). From ia64.h:

   928 /* A C expression whose value is RTL representing the location
of the incoming
   929return address at the beginning of any function, before the
prologue.  This
   930RTL is either a `REG', indicating that the return value is
saved in `REG',
   931or a `MEM' representing a location in the stack.  This enables DWARF2
   932unwind info for C++ EH.  */
   933 #define INCOMING_RETURN_ADDR_RTX gen_rtx_REG (VOIDmode, BR_REG (0))
   934
   935 /* ??? This is not defined because of three problems.
   9361) dwarf2out.c assumes that DWARF_FRAME_RETURN_COLUMN fits
in one byte.
   937The default value is FIRST_PSEUDO_REGISTER which doesn't.
This can be
   938worked around by setting PC_REGNUM to FR_REG (0) which is
an otherwise
   939unused register number.
   9402) dwarf2out_frame_debug core dumps while processing
prologue insns.  We
   941need to refine which insns have RTX_FRAME_RELATED_P set and
which don't.
   9423) It isn't possible to turn off EH frame info by defining
DWARF2_UNIND_INFO
   943to zero, despite what the documentation implies, because it
is tested in
   944a few places with #ifdef instead of #if.  */
   945 #undef INCOMING_RETURN_ADDR_RTX

Here, because INCOMING_RETURN_ADDR_RTX is ultimately undef'ed,
dataflow doesn't see any definition of the return address register,
and happily treats b0 as not live throughout the function body.
Then, global allocator, guided by this information, allocates
b0 for something else - leading to the return address corruption.

Removing the undef leads to an ICE in dwarf2out.c (probably due to 2
in your comment ?).

Certainly from the new dataflow point of view,
we need this macro to be defined,
because, otherwise, the use of b0 in the return is considered a use without
def.
Previously, flow() didn't consider uninitialized registers
and just having a use of b0 in the return was sufficient,
as it made b0 live across the entire function
thanks to flow's backward only live analysis.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552



[Bug target/32481] ICE in df_refs_verify, at df-scan.c:4058

2007-06-27 Thread spark at gcc dot gnu dot org


--- Comment #10 from spark at gcc dot gnu dot org  2007-06-27 18:17 ---
Subject: Bug 32481

Author: spark
Date: Wed Jun 27 18:17:15 2007
New Revision: 126058

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=126058
Log:
2007-06-27  Seongbae Park  [EMAIL PROTECTED]

PR rtl-optimization/32481
* combine.c (adjust_for_new_dest): Rescan the changed insn.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/combine.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481



[Bug target/32481] ICE in df_refs_verify, at df-scan.c:4058

2007-06-25 Thread spark at gcc dot gnu dot org


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||zadeck at gcc dot gnu dot
   ||org
 AssignedTo|zadeck at gcc dot gnu dot   |spark at gcc dot gnu dot org
   |org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-25 16:04:55
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481



[Bug target/32481] ICE in df_refs_verify, at df-scan.c:4058

2007-06-25 Thread spark at gcc dot gnu dot org


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|spark at gcc dot gnu dot org|unassigned at gcc dot gnu
   ||dot org
 Status|ASSIGNED|NEW


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481



[Bug target/32481] ICE in df_refs_verify, at df-scan.c:4058

2007-06-25 Thread spark at gcc dot gnu dot org


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |zadeck at gcc dot gnu dot
   |dot org |org
 Status|NEW |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481



[Bug c++/29365] Unnecessary anonymous namespace warnings

2007-06-25 Thread spark at gcc dot gnu dot org


--- Comment #30 from spark at gcc dot gnu dot org  2007-06-25 18:13 ---
The following patch will essentially disable the warning
for template instantiations in the anonymous namespace.

Index: gcc/cp/decl2.c
===
--- gcc/cp/decl2.c  (revision 125999)
+++ gcc/cp/decl2.c  (working copy)
@@ -1850,7 +1850,9 @@ constrain_class_visibility (tree type)
if (subvis == VISIBILITY_ANON)
  {
if (strcmp (main_input_filename,
-   DECL_SOURCE_FILE (TYPE_MAIN_DECL (ftype
+   DECL_SOURCE_FILE (TYPE_MAIN_DECL (ftype)))
+!(CLASS_TYPE_P (ftype)
+ CLASSTYPE_USE_TEMPLATE (ftype)))
  warning (0, \
 %qT has a field %qD whose type uses the anonymous namespace,
   type, t);
@@ -1871,7 +1873,9 @@ constrain_class_visibility (tree type)
   if (subvis == VISIBILITY_ANON)
 {
  if (strcmp (main_input_filename,
- DECL_SOURCE_FILE (TYPE_MAIN_DECL (TREE_TYPE (t)
+ DECL_SOURCE_FILE (TYPE_MAIN_DECL (TREE_TYPE (t
+!(CLASS_TYPE_P (TREE_TYPE (t))
+ CLASSTYPE_USE_TEMPLATE (TREE_TYPE (t
warning (0, \
 %qT has a base %qT whose type uses the anonymous namespace,
 type, TREE_TYPE (t));


I don't know whether it's possible to do this warning
accurately, as I can't figure out 
how to recover where the template instantiation has happened
at this point in compilation.
DECL_SOURCE_FILE (TYPE_MAIN_DECL (ftype)) 
points to the source file of the declaration of the template itself,
not where the template instantiation happened.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365



[Bug target/32481] ICE in df_refs_verify, at df-scan.c:4058

2007-06-25 Thread spark at gcc dot gnu dot org


--- Comment #6 from spark at gcc dot gnu dot org  2007-06-25 23:13 ---
This patch:

diff -r 36792eca786a gcc/combine.c
--- a/gcc/combine.c Sat Jun 23 16:21:43 2007 +
+++ b/gcc/combine.c Mon Jun 25 23:10:32 2007 +
@@ -2849,6 +2849,7 @@ try_combine (rtx i3, rtx i2, rtx i1, int

  PATTERN (i3) = newpat;
  adjust_for_new_dest (i3);
+ df_insn_rescan (i3);
}
}
 }

at least fixes the immediate problem,
though it's not yet completely clear whether this is the right approach
as I don't know whether the PATTERN (i3) change above 
is supposed to be permanent or not.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481



[Bug target/32481] ICE in df_refs_verify, at df-scan.c:4058

2007-06-25 Thread spark at gcc dot gnu dot org


--- Comment #7 from spark at gcc dot gnu dot org  2007-06-25 23:25 ---
As David suggested, this might be a slightly better fix:

diff -r 36792eca786a gcc/combine.c
--- a/gcc/combine.c Sat Jun 23 16:21:43 2007 +
+++ b/gcc/combine.c Mon Jun 25 23:23:23 2007 +
@@ -2057,6 +2057,8 @@ adjust_for_new_dest (rtx insn)
  of an insn just above it.  Call distribute_links to make a LOG_LINK from
  the next use of that destination.  */
   distribute_links (gen_rtx_INSN_LIST (VOIDmode, insn, NULL_RTX));
+
+  df_insn_rescan (insn);
 }

 /* Return TRUE if combine can reuse reg X in mode MODE.


though I'm still not sure whether this is the right approach in general.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481



[Bug target/32481] ICE in df_refs_verify, at df-scan.c:4058

2007-06-24 Thread spark at gcc dot gnu dot org


--- Comment #2 from spark at gcc dot gnu dot org  2007-06-25 05:30 ---
Confirmed. 
The following commit:

r125972 | zadeck | 2007-06-23 09:21:43 -0700 (Sat, 23 Jun 2007) | 8 lines

2007-06-23  Kenneth Zadeck [EMAIL PROTECTED]

PR middle-end/32437
*dce.c (deletable_insn_p): Add extra parameter and recurse if insn
is a PARALLEL.
(prescan_insns_for_dce): Add extra parameter.


causes the problem.


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |zadeck at gcc dot gnu dot
   |dot org |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32481



[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame

2007-06-23 Thread spark at gcc dot gnu dot org


--- Comment #4 from spark at gcc dot gnu dot org  2007-06-24 01:05 ---
I think Kenny's last patch for PR32437 fixes this as well.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475



[Bug rtl-optimization/32475] [4.3 Regression] function with asm() does not setup stack frame

2007-06-23 Thread spark at gcc dot gnu dot org


--- Comment #6 from spark at gcc dot gnu dot org  2007-06-24 02:01 ---
(In reply to comment #5)
 Subject: Re:  [4.3 Regression] function with asm()
  does not setup stack frame
 
 spark at gcc dot gnu dot org wrote:
  --- Comment #4 from spark at gcc dot gnu dot org  2007-06-24 01:05 
  ---
  I think Kenny's last patch for PR32437 fixes this as well.
 
 

 I have not had a chance to play with this.  i lost my last x86-32 system
 and i have been futzing around with richi trying to build one on my
 x86-64 machines.  So far without success.
 
 it would be good if it went away.  if it has not, i was going to try
 -fno-dse. 
 
 Kenny

I'm positive your patch fixes this,
as the latest trunk doesn't have this problem,
and I've checked out the revision just before your last patch,
and it showed the problem (on i686-unknown-linux-gnu).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32475



[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

2007-06-18 Thread spark at gcc dot gnu dot org


--- Comment #7 from spark at gcc dot gnu dot org  2007-06-18 20:02 ---
Subject: Bug 32339

Author: spark
Date: Mon Jun 18 20:02:33 2007
New Revision: 125825

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125825
Log:
gcc/ChangeLog:

2007-06-18  Seongbae Park  [EMAIL PROTECTED]

PR rtl-optimization/32339
* df-scan.c (df_uses_record): Don't modify flags but just add to
it for df_ref_record.

gcc/testsuite/ChangeLog:

2007-06-18  Martin Michlmayr [EMAIL PROTECTED]

PR rtl-optimization/32339
* gcc.c-torture/compile/pr32339.c: New test.


Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr32339.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcse.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339



[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm

2007-06-18 Thread spark at gcc dot gnu dot org


--- Comment #3 from spark at gcc dot gnu dot org  2007-06-18 20:49 ---
Subject: Bug 32321

Author: spark
Date: Mon Jun 18 20:49:23 2007
New Revision: 125827

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125827
Log:
2007-06-18  Seongbae Park  [EMAIL PROTECTED]

PR rtl-optimization/32321
* gcse.c (replace_store_insn): Update the note before
calling emit_insn_after.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcse.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321



[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

2007-06-18 Thread spark at gcc dot gnu dot org


--- Comment #8 from spark at gcc dot gnu dot org  2007-06-19 04:30 ---
(In reply to comment #7)
 Subject: Bug 32339
 
 Author: spark
 Date: Mon Jun 18 20:02:33 2007
 New Revision: 125825
 
 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125825
 Log:
 gcc/ChangeLog:
 
 2007-06-18  Seongbae Park  [EMAIL PROTECTED]
 
 PR rtl-optimization/32339
 * df-scan.c (df_uses_record): Don't modify flags but just add to
 it for df_ref_record.
 
 gcc/testsuite/ChangeLog:
 
 2007-06-18  Martin Michlmayr [EMAIL PROTECTED]
 
 PR rtl-optimization/32339
 * gcc.c-torture/compile/pr32339.c: New test.
 
 
 Added:
 trunk/gcc/testsuite/gcc.c-torture/compile/pr32339.c
 Modified:
 trunk/gcc/ChangeLog
 trunk/gcc/gcse.c
 trunk/gcc/testsuite/ChangeLog

Please ignore this commit - this patch is for another bug fix,
although the testcase is the correct one.
I'll commit the testcase in a separate patch.
Sorry for the confusion.
Anyway, since this bug has been fixed by my earlier commit,
I'm marking it as fixed.


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339



[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm

2007-06-18 Thread spark at gcc dot gnu dot org


--- Comment #4 from spark at gcc dot gnu dot org  2007-06-19 04:38 ---
Fixed.


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321



[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

2007-06-15 Thread spark at gcc dot gnu dot org


--- Comment #5 from spark at gcc dot gnu dot org  2007-06-15 06:33 ---
Subject: Bug 32339

Author: spark
Date: Fri Jun 15 06:33:24 2007
New Revision: 125736

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125736
Log:
2007-06-14  Seongbae Park  [EMAIL PROTECTED]

PR rtl-optimization/32339
* df-scan.c (df_uses_record): Don't modify flags but just add to it for
df_ref_record.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/df-scan.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339



[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

2007-06-14 Thread spark at gcc dot gnu dot org


--- Comment #1 from spark at gcc dot gnu dot org  2007-06-14 14:10 ---
What's the target tripe ? I presume thi sis ia64-unknown-linux ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339



[Bug target/32341] undefined reference to `df_set_regs_ever_live_p'

2007-06-14 Thread spark at gcc dot gnu dot org


--- Comment #2 from spark at gcc dot gnu dot org  2007-06-14 14:33 ---
Subject: Bug 32341

Author: spark
Date: Thu Jun 14 14:33:21 2007
New Revision: 125715

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=125715
Log:
2007-06-14  Rask Ingemann Lambertsen  [EMAIL PROTECTED]

PR target/32341
* config/v850/v850.c: Include dataflow header file.
(substitute_ep_register): Fix typo.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/v850/v850.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32341



[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

2007-06-14 Thread spark at gcc dot gnu dot org


--- Comment #3 from spark at gcc dot gnu dot org  2007-06-14 17:52 ---
This is a bug in df-scan.c, marking regs unnecessarily as read-write,
which lead to unnecessarily stretched live ranges for regs involved in pre/post
modify insn. I'm working on it.


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-14 17:52:16
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339



[Bug rtl-optimization/32339] [4.3 Regression] ICE in insert_save, at caller-save.c:726

2007-06-14 Thread spark at gcc dot gnu dot org


--- Comment #4 from spark at gcc dot gnu dot org  2007-06-14 18:31 ---
diff -r 8522653fd69d gcc/df-scan.c
--- a/gcc/df-scan.c Thu Jun 14 00:17:05 2007 +
+++ b/gcc/df-scan.c Thu Jun 14 11:29:46 2007 -0700
@@ -2982,9 +2982,9 @@ df_uses_record (struct df_collection_rec
 case PRE_MODIFY:
 case POST_MODIFY:
   /* Catch the def of the register being modified.  */
-  flags |= DF_REF_READ_WRITE | DF_REF_PRE_POST_MODIFY;
   df_ref_record (collection_rec, XEXP (x, 0), XEXP (x, 0), bb, insn,
-DF_REF_REG_DEF, flags);
+DF_REF_REG_DEF,
+ flags | DF_REF_READ_WRITE | DF_REF_PRE_POST_MODIFY);

   /* ... Fall through to handle uses ...  */

This patch fixes the problem.
I'm starting the testing.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32339



[Bug middle-end/32321] [4.3 Regression] ICE in df_refs_verify with -fgcse-sm

2007-06-14 Thread spark at gcc dot gnu dot org


--- Comment #2 from spark at gcc dot gnu dot org  2007-06-14 19:49 ---
The problem is reproducible also on x86-64.
The following patch seems to fix the ICE.
I'll start a bootstrap/testing.

*** /tmp/gcse.c 2007-06-14 19:46:27.0 +
--- gcc/gcse.c  2007-06-14 19:44:19.0 +
*** replace_store_insn (rtx reg, rtx del, ba
*** 6341,6357 

mem = smexpr-pattern;
insn = gen_move_insn (reg, SET_SRC (single_set (del)));
-   insn = emit_insn_after (insn, del);
-
-   if (dump_file)
- {
-   fprintf (dump_file,
-  STORE_MOTION  delete insn in BB %d:\n  , bb-index);
-   print_inline_rtx (dump_file, del, 6);
-   fprintf (dump_file, \nSTORE MOTION  replaced with insn:\n  );
-   print_inline_rtx (dump_file, insn, 6);
-   fprintf (dump_file, \n);
- }

for (ptr = ANTIC_STORE_LIST (smexpr); ptr; ptr = XEXP (ptr, 1))
  if (XEXP (ptr, 0) == del)
--- 6341,6346 
*** replace_store_insn (rtx reg, rtx del, ba
*** 6379,6384 
--- 6368,6385 
XEXP (note, 0) = insn;
  }

+   insn = emit_insn_after (insn, del);
+
+   if (dump_file)
+ {
+   fprintf (dump_file,
+  STORE_MOTION  delete insn in BB %d:\n  , bb-index);
+   print_inline_rtx (dump_file, del, 6);
+   fprintf (dump_file, \nSTORE MOTION  replaced with insn:\n  );
+   print_inline_rtx (dump_file, insn, 6);
+   fprintf (dump_file, \n);
+ }
+
delete_insn (del);

/* Now we must handle REG_EQUAL notes whose contents is equal to the mem;


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-14 19:49:10
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32321



[Bug target/32347] ICE on gcc/testsuite/gcc-dg/vmx/ops.c

2007-06-14 Thread spark at gcc dot gnu dot org


--- Comment #3 from spark at gcc dot gnu dot org  2007-06-14 21:10 ---
Adding our bugmaster to CC.


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spark at gcc dot gnu dot
   ||org, pinskia at gcc dot gnu
   ||dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32347



[Bug middle-end/32349] ICE in df_refs_verify with -O2 -fmodulo-sched for spec tests

2007-06-14 Thread spark at gcc dot gnu dot org


--- Comment #1 from spark at gcc dot gnu dot org  2007-06-14 21:12 ---
Kenny, can you take a look ?


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||zadeck at gcc dot gnu dot
   ||org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32349



[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

2007-06-13 Thread spark at gcc dot gnu dot org


--- Comment #11 from spark at gcc dot gnu dot org  2007-06-14 03:53 ---
(In reply to comment #10)
 Subject: Re:  [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
 
  It's my turn to ask: so what information does hppa_can_use_return_p
  need to make the decision ?
 
 We need to know that the return pointer (r2) is not used and that
 the function is a leaf function (i.e., that the incoming value in
 r2 is unchanged).  Calls clobber r2.
 
 Dave

Sounds like the following patch would work:

diff -r 149399c845b5 gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cTue Jun 12 15:49:27 2007 -0700
+++ b/gcc/config/pa/pa.cWed Jun 13 18:37:17 2007 -0700
@@ -4415,7 +4415,7 @@ hppa_can_use_return_insn_p (void)
 {
   return (reload_completed
   (compute_frame_size (get_frame_size (), 0) ? 0 : 1)
-  df_hard_reg_used_count (2) == 1
+  DF_REG_DEF_COUNT (2) == 0
   ! frame_pointer_needed);
 }


This essentially checks if r2 is ever written within the function
(including the calls since r2 is included in the CALL_USED_REGS).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296



[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

2007-06-12 Thread spark at gcc dot gnu dot org


--- Comment #4 from spark at gcc dot gnu dot org  2007-06-12 21:43 ---
This patch should fix the bootstrap. I was in the process of running some
regtests when gsyprf11 got reset.

diff -r f78a38a8334b gcc/config/pa/pa.c
--- a/gcc/config/pa/pa.cThu May 31 11:43:34 2007 -0700
+++ b/gcc/config/pa/pa.cTue Jun 05 09:36:50 2007 -0700
@@ -47,6 +47,7 @@ Boston, MA 02110-1301, USA.  */
 #include tm_p.h
 #include target.h
 #include target-def.h
+#include df.h

 /* Return nonzero if there is a bypass for the output of
OUT_INSN and the fp store IN_INSN.  */
@@ -4384,7 +4385,7 @@ hppa_can_use_return_insn_p (void)
 {
   return (reload_completed
   (compute_frame_size (get_frame_size (), 0) ? 0 : 1)
-  ! df_regs_ever_live_p (2)
+  df_hard_reg_used_count (2) == 1
   ! frame_pointer_needed);
 }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296



[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

2007-06-12 Thread spark at gcc dot gnu dot org


--- Comment #6 from spark at gcc dot gnu dot org  2007-06-12 23:07 ---
(In reply to comment #5)
 Subject: Re:  [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
 
  @@ -4384,7 +4385,7 @@ hppa_can_use_return_insn_p (void)
   {
 return (reload_completed
 (compute_frame_size (get_frame_size (), 0) ? 0 : 1)
  -  ! df_regs_ever_live_p (2)
  +  df_hard_reg_used_count (2) == 1
 ! frame_pointer_needed);
   }
 
 Don't understand difference between df_regs_ever_live_p and
 f-hard_regs_live_count, and why you are checking for a count of 1.

hppa_can_use_return_insn_p() is called 
from return insn pattern in pa.md.
The pattern looks:

(define_insn return
  [(return)
   (use (reg:SI 2))
   (const_int 0)]
  hppa_can_use_return_insn_p ()
  *

i.e. there's a use of reg 2.

Before dataflow branch got merged, regs_ever_live(2) was not true
for reg 2, even though it is used at the return (hence it's live
throughout the function body) - unless there's some other use
within the function.

Now, with df, we always have the correct and precise regs_ever_live.
Since the condition hppa_can_use_return_p() is checking 
is really that there are no other insn that uses reg 2
AND since we know the pattern has a use of reg 2,
checking the number of use count to be 1
checks effectively the same assertion.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296



[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

2007-06-12 Thread spark at gcc dot gnu dot org


--- Comment #9 from spark at gcc dot gnu dot org  2007-06-13 03:48 ---
(In reply to comment #8)
 Subject: Re:  [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*
 
  I think the solution is to remove this check from the insn definition
  in pa.md and change the check in hppa_can_use_return_insn_p()
  to ! df_hard_reg_used_p(). 
 
 This doesn't work.  The problem seems to be that df_regs_ever_live (2)
 doesn't provide an indication that a function isn't a leaf function
 anymore.  Calls clobber register r2 but they don't us it.

It's my turn to ask: so what information does hppa_can_use_return_p
need to make the decision ?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296



[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

2007-06-11 Thread spark at gcc dot gnu dot org


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-06-12 01:01:30
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296



[Bug rtl-optimization/32296] [4.3 Regression] Bootstrap failure in stage1 on hppa*-*-*

2007-06-11 Thread spark at gcc dot gnu dot org


--- Comment #2 from spark at gcc dot gnu dot org  2007-06-12 01:14 ---
This is a one-liner but I can't access the machine holding the patch now
(gsyprf11 on HP's test cluster) and I can't remember the line :(


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-06-12 01:01:30 |2007-06-12 01:14:38
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32296



[Bug c++/29365] Unnecessary anonymous namespace warnings

2007-06-05 Thread spark at gcc dot gnu dot org


--- Comment #25 from spark at gcc dot gnu dot org  2007-06-05 22:37 ---
(In reply to comment #24)
 any news?

I have (or had, since I seem to have lost it) a patch that will prevent the
invalid warning for the template case, but it will effectively prevent the
valid warning for other template case as well, and I haven't found an easy way
to make it accurate yet. I'll get back to this once dataflow branch is
integrated and stablized in the mainline, unless someone else fixes this before
then.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365



[Bug c/32044] udivdi3 counterproductive, unwarranted use

2007-05-22 Thread spark at gcc dot gnu dot org


--- Comment #3 from spark at gcc dot gnu dot org  2007-05-22 21:11 ---
(In reply to comment #0)
 First I am herewith re-afirming my formal request for Mr. Pinsk to refrain 
 from
 having anything to do with my submissions.

Please refrain from insulting others.

 According to my (admittedly second hand (Fifth Edition of C A Reference
 Manual
 by Samuel P. Harbison III  Guy L. Stelle Jr) reading; GCC, by not providing 
 a 
 means to disable the use of libgcc (including udivdi3) is not in strict 
 conformance with the C standard for free-standing use through C99. __udivdi3 
 is
 a reserved identifier 
 and hence non-conforming.

If you want to play the language laywer,
please read the C standard and tell me which clause this gcc behavior violates.

 As a 
 practical matter the use of __builtin_expect could be taken as signal to 
 allow only reordering of instructions (to avoid pipeline stalls and 
 reloading of caches) are to be avoided in the marked unlikely cases. Any 
 fundamental changes like exchanging a while and a subtraction for a
 non-hardware 
 divide should no occur

The meaning of __builtin_expect is as defined in the documentation.
This particular transformation has nothing to do with __builtin_expect.
The transformation happens regardless of __builtin_expect.

scev_const_prop eliminates the loop by replacing
the final value with an expression using divide.
Probably the right approach would be to prevent this from happening
ifthe final value expression looks expensive
(like DImode divide on targets without native DImode divide).


The following patch avoids the situation 
(probably the condition check is too conservative
so this isn't fully cooked yet):

diff -r f01bb94713f4 gcc/tree-scalar-evolution.c
--- a/gcc/tree-scalar-evolution.c   Mon May 14 13:52:18 2007 +
+++ b/gcc/tree-scalar-evolution.c   Tue May 22 20:09:08 2007 +
@@ -252,6 +252,9 @@ 02110-1301, USA.  */
 #include tree-pass.h
 #include flags.h
 #include params.h
+/* For optab access.  */
+#include expr.h
+#include optabs.h

 static tree analyze_scalar_evolution_1 (struct loop *, tree, tree);

@@ -2942,6 +2945,7 @@ scev_const_prop (void)
   edge exit;
   tree def, rslt, ass, niter;
   block_stmt_iterator bsi;
+  optab op;

   /* If we do not know exact number of iterations of the loop, we cannot
 replace the final value.  */
@@ -2957,6 +2961,10 @@ scev_const_prop (void)
 the elimination of the final value may reveal.  Therefore, we now
 eliminate the final values of induction variables unconditionally.  */
   if (niter == chrec_dont_know)
+   continue;
+  op = optab_for_tree_code (TREE_CODE (niter), TREE_TYPE (niter));
+  if (op-handlers[TYPE_MODE (TREE_TYPE (niter))].insn_code ==
CODE_FOR_nothing
+ EDGE_FREQUENCY (exit)  500)
continue;

   /* Ensure that it is possible to insert new statements somewhere.  */


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044



[Bug c++/31663] [4.3 Regression] Segfault in constrain_class_visibility with anonymous namespace

2007-05-02 Thread spark at gcc dot gnu dot org


--- Comment #3 from spark at gcc dot gnu dot org  2007-05-03 00:11 ---
Subject: Bug 31663

Author: spark
Date: Wed May  2 23:11:13 2007
New Revision: 124363

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=124363
Log:
gcc/ChangeLog:
2007-05-02  Seongbae Park  [EMAIL PROTECTED]

PR c++/31663
* c-common.c (strip_pointer_or_array_types): New function.
* c-common.h (strip_pointer_or_array_types): New function declaration.

gcc/cp/ChangeLog:
2007-05-02  Seongbae Park  [EMAIL PROTECTED]

PR c++/31663
* decl2.c (constrain_class_visibility): 
Use strip_pointer_or_array_types instead of strip_array_types.

gcc/testsuite/ChangeLog:
2007-05-02  Seongbae Park  [EMAIL PROTECTED]

PR C++/31663
* g++.dg/warn/anonymous-namespace-2.C: New. 
* g++.dg/warn/anonymous-namespace-2.h: New. 


Added:
trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-2.C
trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-2.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-common.c
trunk/gcc/c-common.h
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31663



[Bug c++/31663] [4.3 Regression] Segfault in constrain_class_visibility with anonymous namespace

2007-04-23 Thread spark at gcc dot gnu dot org


--- Comment #2 from spark at gcc dot gnu dot org  2007-04-23 16:53 ---
My patch (which is still waiting for a review) should fix this.


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
   |dot org |
 Status|UNCONFIRMED |ASSIGNED
 Ever Confirmed|0   |1
   Last reconfirmed|-00-00 00:00:00 |2007-04-23 16:53:04
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31663



[Bug c++/29365] Unnecessary anonymous namespace warnings

2007-04-17 Thread spark at gcc dot gnu dot org


--- Comment #17 from spark at gcc dot gnu dot org  2007-04-17 17:36 ---
I'm testing the following patch (which fixes the ICE).
It turned out to be a latent bug in the warning code not handling pointer types
correctly. 

Index: cp/decl2.c
===
--- cp/decl2.c  (revision 123879)
+++ cp/decl2.c  (working copy)
@@ -1856,7 +1856,7 @@ constrain_class_visibility (tree type)
   for (t = TYPE_FIELDS (type); t; t = TREE_CHAIN (t))
 if (TREE_CODE (t) == FIELD_DECL  TREE_TYPE (t) != error_mark_node)
   {
-   tree ftype = strip_array_types (TREE_TYPE (t));
+   tree ftype = strip_pointer_or_array_types (TREE_TYPE (t));
int subvis = type_visibility (ftype);

if (subvis == VISIBILITY_ANON)
Index: c-common.c
===
--- c-common.c  (revision 123879)
+++ c-common.c  (working copy)
@@ -3894,6 +3894,15 @@ strip_pointer_operator (tree t)
   return t;
 }

+/* Recursively remove pointer or array type from TYPE. */
+tree
+strip_pointer_or_array_types (tree t)
+{
+  while (TREE_CODE (t) == ARRAY_TYPE || POINTER_TYPE_P (t))
+t = TREE_TYPE (t);
+  return t;
+}
+
 /* Used to compare case labels.  K1 and K2 are actually tree nodes
representing case labels, or NULL_TREE for a `default' label.
Returns -1 if K1 is ordered before K2, -1 if K1 is ordered after
Index: c-common.h
===
--- c-common.h  (revision 123879)
+++ c-common.h  (working copy)
@@ -727,6 +727,7 @@ extern bool c_promoting_integer_type_p (
 extern int self_promoting_args_p (tree);
 extern tree strip_array_types (tree);
 extern tree strip_pointer_operator (tree);
+extern tree strip_pointer_or_array_types (tree);
 extern HOST_WIDE_INT c_common_to_target_charset (HOST_WIDE_INT);

 /* This is the basic parsing function.  */


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365



[Bug c++/29365] Unnecessary anonymous namespace warnings

2007-04-16 Thread spark at gcc dot gnu dot org


--- Comment #13 from spark at gcc dot gnu dot org  2007-04-16 17:49 ---
Subject: Bug 29365

Author: spark
Date: Mon Apr 16 17:49:02 2007
New Revision: 123879

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123879
Log:
gcc/ChangeLog:

2007-04-16  Seongbae Park [EMAIL PROTECTED]

PR c++/29365

* cp/decl2.c (constrain_class_visibility):
Do not warn about the use of anonymous namespace in the main input
file.

gcc/testsuite/ChangeLog:

2007-04-16  Seongbae Park [EMAIL PROTECTED]

PR c++/29365
Testcase for c++ anonymous namespace warning

* g++.dg/warn/anonymous-namespace-1.C: New test
* g++.dg/warn/anonymous-namespace-1.h: New test


Added:
trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-1.C
trunk/gcc/testsuite/g++.dg/warn/anonymous-namespace-1.h
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365



[Bug c++/29365] Unnecessary anonymous namespace warnings

2007-04-03 Thread spark at gcc dot gnu dot org


--- Comment #8 from spark at gcc dot gnu dot org  2007-04-03 23:50 ---
The following patch addresses the problem.
Do we want to add a flag to control this ?

--- a/gcc/cp/decl2.cMon Apr 02 15:48:00 2007 +
+++ b/gcc/cp/decl2.cTue Apr 03 22:45:49 2007 +
@@ -1860,9 +1860,13 @@ constrain_class_visibility (tree type)
int subvis = type_visibility (ftype);

if (subvis == VISIBILITY_ANON)
- warning (0, \
+ {
+   if (strcmp (main_input_filename,
+   DECL_SOURCE_FILE (TYPE_MAIN_DECL (ftype
+ warning (0, \
 %qT has a field %qD whose type uses the anonymous namespace,
-  type, t);
+  type, t);
+ }
else if (IS_AGGR_TYPE (ftype)
  vis  VISIBILITY_HIDDEN
  subvis = VISIBILITY_HIDDEN)
@@ -1877,9 +1881,13 @@ constrain_class_visibility (tree type)
   int subvis = type_visibility (TREE_TYPE (t));

   if (subvis == VISIBILITY_ANON)
-   warning (0, \
+{
+ if (strcmp (main_input_filename,
+ DECL_SOURCE_FILE (TYPE_MAIN_DECL (TREE_TYPE (t)
+   warning (0, \
 %qT has a base %qT whose type uses the anonymous namespace,
-type, TREE_TYPE (t));
+type, TREE_TYPE (t));
+   }
   else if (vis  VISIBILITY_HIDDEN
subvis = VISIBILITY_HIDDEN)
warning (OPT_Wattributes, \


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365



[Bug c++/29365] Unnecessary anonymous namespace warnings

2007-04-03 Thread spark at gcc dot gnu dot org


--- Comment #10 from spark at gcc dot gnu dot org  2007-04-04 00:18 ---
(In reply to comment #9)
 (In reply to comment #8)
  The following patch addresses the problem.
  Do we want to add a flag to control this ?
 
 Except if you look at the file name, you could get a case where you are no
 longer warning about.

That's why I asked if we want to add a flag to enable/disable this 
- although I think my patch is a reasonable compromise as a default,
it's not perfect (it can never be perfect unless we do whole-program analysis).

The patch prevents the warning IF the anonymous namespace
was in the same main source file that it's currently compiling (e.g. *.cc
file).
I think this covers bulk of the false positives with very small number of the
false negatives. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29365



[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF

2007-03-26 Thread spark at gcc dot gnu dot org


--- Comment #33 from spark at gcc dot gnu dot org  2007-03-26 16:54 ---
(In reply to comment #31)
 Here is a new patch.  I need someone to test on SPEC.  It is very simple.
 
 Index: transfer.c
 ===
 *** transfer.c  (revision 123205)
 --- transfer.c  (working copy)
 *** next_record_r (st_parameter_dt *dtp)
 *** 2228,2234 
 break;
   }
 
 !   if (dtp-u.p.current_unit-flags.access == ACCESS_SEQUENTIAL)
   test_endfile (dtp-u.p.current_unit);
   }
 
 --- 2228,2235 
 break;
   }
 
 !   if (dtp-u.p.current_unit-flags.access == ACCESS_SEQUENTIAL
 !!dtp-u.p.namelist_mode)
   test_endfile (dtp-u.p.current_unit);
   }

This patch doesn't break 200.sixtrack (when added on top of the Jerry's
previous patch above).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052



[Bug c/31367] Should not warn about use of deprecated type in deprecated struct

2007-03-26 Thread spark at gcc dot gnu dot org


--- Comment #3 from spark at gcc dot gnu dot org  2007-03-27 00:56 ---
# cat -n t.c
 1  typedef __attribute__((deprecated)) int foo;
 2  typedef
 3  struct
 4  __attribute__((deprecated))
 5  bar1
 6  {
 7foo baz;
 8  }
 9  bop1;
10
11  typedef
12  __attribute__((deprecated))
13  struct
14  bar2
15  {
16foo baz;
17  } bop2;
18
19  typedef
20  struct
21  bar3
22  {
23foo baz;
24  }
25  __attribute__((deprecated))
26  bop3;
27
28  typedef
29  struct
30  bar4
31  {
32foo baz;
33  }
34  bop4
35  __attribute__((deprecated));
# ~/local/pkg/4.1/bin/gcc -c t.c
t.c:7: warning: 'foo' is deprecated
t.c:9: warning: 'bar1' is deprecated (declared at t.c:6)
t.c:16: warning: 'foo' is deprecated
t.c:23: warning: 'foo' is deprecated
t.c:26: warning: 'bar3' is deprecated (declared at t.c:22)
t.c:32: warning: 'foo' is deprecated
#

I'm not sure what to make of this, 
but there seems to be some subtleties regarding 
which declaration the attribute applies to.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31367



[Bug tree-optimization/31136] [4.2 Regression] FRE ignores bit-field truncation (C and C++ front-end don't produce bit-field truncation

2007-03-22 Thread spark at gcc dot gnu dot org


--- Comment #7 from spark at gcc dot gnu dot org  2007-03-23 05:00 ---
Follow up on Joseph's analysis:

The problematic STRIP_SIGN_NOPS() call is from fold_unary()
which is called from try_combine_conversion() in tree-ssa-pre.c.

STRIP_SIGN_NOPS() is called with the expression:

 nop_expr 0x866f220
type integer_type 0xf7e30678 public unsigned QI
size integer_cst 0xf7d781e0 constant invariant 8
unit size integer_cst 0xf7d781f8 constant invariant 1
align 8 symtab 0 alias set -1 precision 4 min integer_cst 0xf7e32618
0 max integer_cst 0xf7e32630 15

arg 0 integer_cst 0xf7e327b0 type integer_type 0xf7e306d4 constant
invariant 31

and it stripes away the conversion,
leaving only integer constant 31.
This is clearly wrong as it removes the downconversion of precision.

Following patch (against 4.2 branch) seems to fix the problem:

Index: tree.h
===
--- tree.h  (revision 123088)
+++ tree.h  (working copy)
@@ -912,7 +912,9 @@ extern void omp_clause_range_check_faile
  (TYPE_MODE (TREE_TYPE (EXP))\
 == TYPE_MODE (TREE_TYPE (TREE_OPERAND (EXP, 0  \
  (TYPE_UNSIGNED (TREE_TYPE (EXP))\
-== TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (EXP, 0) \
+== TYPE_UNSIGNED (TREE_TYPE (TREE_OPERAND (EXP, 0\
+ (TYPE_PRECISION (TREE_TYPE (EXP))   \
+= TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (EXP, 0)\
 (EXP) = TREE_OPERAND (EXP, 0)

 /* Like STRIP_NOPS, but don't alter the TREE_TYPE either.  */


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31136



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-20 Thread spark at gcc dot gnu dot org


--- Comment #17 from spark at gcc dot gnu dot org  2007-03-20 15:42 ---
Subject: Bug 30590

Author: spark
Date: Tue Mar 20 15:42:37 2007
New Revision: 123087

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123087
Log:
2007-03-19  Seongbae Park [EMAIL PROTECTED]

PR tree-optimization/30590
* g++.dg/opt/pr30590.C: New testcase.


Added:
trunk/gcc/testsuite/g++.dg/opt/pr30590.C
Modified:
trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-20 Thread spark at gcc dot gnu dot org


--- Comment #18 from spark at gcc dot gnu dot org  2007-03-20 16:44 ---
Subject: Bug 30590

Author: spark
Date: Tue Mar 20 16:44:00 2007
New Revision: 123089

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123089
Log:
2007-03-20  Seongbae Park [EMAIL PROTECTED]

PR tree-optimization/30590
* g++.dg/opt/pr30590.C: New testcase.


Added:
branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/pr30590.C
Modified:
branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-20 Thread spark at gcc dot gnu dot org


--- Comment #19 from spark at gcc dot gnu dot org  2007-03-20 16:45 ---
Subject: Bug 30590

Author: spark
Date: Tue Mar 20 16:44:54 2007
New Revision: 123090

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123090
Log:
2007-03-20  Seongbae Park [EMAIL PROTECTED]

PR tree-optimization/30590
* g++.dg/opt/pr30590.C: New testcase.


Added:
branches/gcc-4_1-branch/gcc/testsuite/g++.dg/opt/pr30590.C
Modified:
branches/gcc-4_1-branch/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-19 Thread spark at gcc dot gnu dot org


--- Comment #14 from spark at gcc dot gnu dot org  2007-03-20 04:45 ---
Subject: Bug 30590

Author: spark
Date: Tue Mar 20 04:45:14 2007
New Revision: 123083

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123083
Log:
2007-03-19  Seongbae Park [EMAIL PROTECTED]

PR tree-optimization/30590
* tree-nrv.c (tree_nrv): Check for the partial update
of the return value.


Modified:
branches/gcc-4_1-branch/gcc/ChangeLog
branches/gcc-4_1-branch/gcc/tree-nrv.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-19 Thread spark at gcc dot gnu dot org


--- Comment #15 from spark at gcc dot gnu dot org  2007-03-20 04:50 ---
Fixed in 4.1, 4.2 and 4.3


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-15 Thread spark at gcc dot gnu dot org


--- Comment #13 from spark at gcc dot gnu dot org  2007-03-15 23:48 ---
Subject: Bug 30590

Author: spark
Date: Thu Mar 15 23:48:13 2007
New Revision: 122964

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122964
Log:
2007-03-15  Seongbae Park [EMAIL PROTECTED]

PR tree-optimization/30590
* tree-nrv.c (tree_nrv): Check for the partial update
of the return value.


Modified:
branches/gcc-4_2-branch/gcc/ChangeLog
branches/gcc-4_2-branch/gcc/tree-nrv.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-13 Thread spark at gcc dot gnu dot org


--- Comment #7 from spark at gcc dot gnu dot org  2007-03-13 16:15 ---
tree-nrv code doesn't see:

bb 2:
  retval.type = 0;

because it only looks at GIMPLE_MODIFY with the operand 0 as the return value.
In this case, there's GIMPLE_MODIFY of the component of the return value
hence not all modification to the return value.
The following patch seems to get around the problem:

Index: tree-nrv.c
===
--- tree-nrv.c  (revision 122871)
+++ tree-nrv.c  (working copy)
@@ -163,6 +163,12 @@ tree_nrv (void)
 result_type))
return 0;
}
+ else if (TREE_CODE (stmt) == GIMPLE_MODIFY_STMT
+   TREE_CODE (GIMPLE_STMT_OPERAND (stmt, 0)) ==
COMPONENT_REF
+   TREE_OPERAND (GIMPLE_STMT_OPERAND (stmt, 0), 0) ==
result)
+   /* If there's any MODIFY of component of RESULT,
+  then bail out.  */
+   return 0;
}
 }


I'm not sure this is sufficient - can there be any other 
gimple statement combination that modifies only part of RESULT ?


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-13 Thread spark at gcc dot gnu dot org


--- Comment #9 from spark at gcc dot gnu dot org  2007-03-13 18:29 ---
How does this one look ? If it looks reasonable, I'll start the testing with
the mainline.

Index: tree-nrv.c
===
--- tree-nrv.c  (revision 122871)
+++ tree-nrv.c  (working copy)
@@ -163,6 +163,14 @@ tree_nrv (void)
 result_type))
return 0;
}
+ else if (TREE_CODE (stmt) == GIMPLE_MODIFY_STMT)
+   {
+ tree addr = get_base_address (GIMPLE_STMT_OPERAND (stmt, 0));
+  /* If there's any MODIFY of component of RESULT,
+ then bail out.  */
+ if (addr  addr == result)
+   return 0;
+   }
}
 }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-13 Thread spark at gcc dot gnu dot org


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-01-25 20:11:47 |2007-03-13 21:26:47
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug c++/30988] [4.1/4.2/4.3 Regression] Incorrect no return statement warning with __attribute__ ((noreturn)) and __FUNCTION__

2007-03-13 Thread spark at gcc dot gnu dot org


--- Comment #3 from spark at gcc dot gnu dot org  2007-03-13 22:57 ---
This is somewhat complicated. 
The extra type cast causes
different code paths to be taken.
In particular, in finish_call_expr() in cp/semantics.c:

  if (processing_template_decl)
{
  if (type_dependent_expression_p (fn)
  || any_type_dependent_arguments_p (args))
{
  result = build_nt_call_list (fn, args);
  KOENIG_LOOKUP_P (result) = koenig_p;
  return result;
}
  if (!BASELINK_P (fn)
   TREE_CODE (fn) != PSEUDO_DTOR_EXPR
   TREE_TYPE (fn) != unknown_type_node)
fn = build_non_dependent_expr (fn);
  args = build_non_dependent_args (orig_args);



With the type cast, 
build_over_call() is called eventually
which checks TREE_THIS_VOLATILE() for the callee function decl
and mark the current function (i.e. caller A::g) as returns_abnormally.
The lack of the type cast triggers
any_type_dependent_arguments_p(args) above,
leading to build_nt_call_list() which doesn't do this marking
of the returns_abnormally.

Now, not being familiar with the c++ frontend,
I'm not sure where exactly we should do the checking
of TREE_THIS_VOLATILE() for the callee decl.

The following patch seems to fix the problem 
(though I can't even tell whether this is the right approach):

diff -r 15a559a8fcf0 gcc/cp/semantics.c
--- a/gcc/cp/semantics.cMon Mar 12 15:38:22 2007 -0700
+++ b/gcc/cp/semantics.cTue Mar 13 15:48:45 2007 -0700
@@ -1816,6 +1816,10 @@ finish_call_expr (tree fn, tree args, bo
  || any_type_dependent_arguments_p (args))
{
  result = build_nt_call_list (fn, args);
+
+ if (fn  TREE_THIS_VOLATILE (fn)  cfun)
+   current_function_returns_abnormally = 1;
+
  KOENIG_LOOKUP_P (result) = koenig_p;
  return result;
}


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30988



[Bug inline-asm/28686] ebp from clobber list used as operand

2007-03-13 Thread spark at gcc dot gnu dot org


--- Comment #8 from spark at gcc dot gnu dot org  2007-03-13 23:43 ---
I believe all issues are fixed at this point,
except for the extra error message of can't find a register.
But since it's accompanied with a proper error message,
I don't think this is a problem anymore.

$gcc -fPIC -fomit-frame-pointer -O2 -S t.c  grep DEBUG t.s
#DEBUG %0=(%esp), clobber: %ebp, ...
$gcc -DNBEFORE=1 -fPIC -fomit-frame-pointer -O2 -S t.c  grep DEBUG t.s
#DEBUG %0=(%esp), clobber: %ebp, ...
$gcc-O1 -S t.c $@  grep DEBUG t.s
t.c: In function 'test_function':
t.c:15: error: can't find a register in class 'GENERAL_REGS' while reloading
'asm'
t.c:15: error: 'asm' operand has impossible constraints
$gcc   -O1 -fPIC -S t.c $@  grep DEBUG t.s
t.c: In function 'test_function':
t.c:20: error: bp cannot be used in asm here
t.c:15: error: can't find a register in class 'GENERAL_REGS' while reloading
'asm'
t.c:15: error: 'asm' operand has impossible constraints
$gcc -fPIC  -O0 -S t.c  grep DEBUG t.s
t.c: In function 'test_function':
t.c:20: error: bp cannot be used in asm here
$gcc -fPIC  -O0 -S t.c -fomit-frame-pointer  grep DEBUG
t.s
#DEBUG %0=12(%esp), clobber: %ebp, ...


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686



[Bug tree-optimization/30590] [4.1/4.2/4.3 Regression] tree-nrv optimization clobbers return variable

2007-03-13 Thread spark at gcc dot gnu dot org


--- Comment #11 from spark at gcc dot gnu dot org  2007-03-14 05:48 ---
Subject: Bug 30590

Author: spark
Date: Wed Mar 14 05:48:35 2007
New Revision: 122909

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=122909
Log:
2007-03-13  Seongbae Park [EMAIL PROTECTED]

PR tree-optimization/30590
* tree-nrv.c (tree_nrv): Check for the partial update of the
return value.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-nrv.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30590



[Bug middle-end/30984] [4.1/4.2/4.3 Regression] ICE with computed goto and constants

2007-03-12 Thread spark at gcc dot gnu dot org


--- Comment #4 from spark at gcc dot gnu dot org  2007-03-12 23:46 ---
This little patch below seems to get around the problem,
though I'm not really sure this is sufficient or not.

Index: tree-cfg.c
===
--- tree-cfg.c  (revision 122871)
+++ tree-cfg.c  (working copy)
@@ -2039,7 +2039,9 @@ find_taken_edge (basic_block bb, tree va
 return find_taken_edge_switch_expr (bb, val);

   if (computed_goto_p (stmt))
-return find_taken_edge_computed_goto (bb, TREE_OPERAND( val, 0));
+return (TREE_CODE (val) == LABEL_EXPR)
+  ? find_taken_edge_computed_goto (bb, TREE_OPERAND(val, 0))
+  : NULL;

   gcc_unreachable ();
 }
@@ -2054,6 +2056,8 @@ find_taken_edge_computed_goto (basic_blo
   basic_block dest;
   edge e = NULL;

+  gcc_assert (TREE_CODE (val) == LABEL_EXPR);
+
   dest = label_to_block (val);
   if (dest)
 {


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30984



[Bug inline-asm/28686] ebp from clobber list used as operand

2007-02-06 Thread spark at gcc dot gnu dot org


--- Comment #7 from spark at gcc dot gnu dot org  2007-02-06 19:43 ---
Subject: Bug 28686

Author: spark
Date: Tue Feb  6 19:43:41 2007
New Revision: 121663

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121663
Log:
2007-02-06  Seongbae Park [EMAIL PROTECTED]

PR inline-asm/28686
* global.c (compute_regsets): New function.
(global_alloc): Refactored ELIMINABLE_REGSET
and NO_GLOBAL_ALLOC_REGS computation out.
(rest_of_handle_global_alloc): Call compute_regsets()
for non-optimizing case.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/global.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686



[Bug inline-asm/28686] ebp from clobber list used as operand

2007-02-01 Thread spark at gcc dot gnu dot org


--- Comment #5 from spark at gcc dot gnu dot org  2007-02-01 17:47 ---
-O1 error problem is due to constant assignment of var.
If you replace:
  long var = 42; 
with something like:
  long var = func();

It compiles without an error (though it still has the #3 problem
of using %ebp even though it's marked clobbered).

This is a corner case for reload, because it knows the register contains a
constant, and thinks there will be at least some scratch register to load it
to. Unfortunately, due to the problematic asm statement having clobbers for all
registers (except %ebp, but %ebp is not available for general allocation
without -fomit-frame-pointer) there's no register available to load the
constant to.

So, the workaround for this problem is to have a local variable that's not
initialized from a constant.

So I'm deferring this #2 problem, and will take a look at #3 now.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686



[Bug inline-asm/28686] ebp from clobber list used as operand

2007-02-01 Thread spark at gcc dot gnu dot org


--- Comment #6 from spark at gcc dot gnu dot org  2007-02-01 23:15 ---
Subject: Bug 28686

Author: spark
Date: Thu Feb  1 23:15:13 2007
New Revision: 121477

URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=121477
Log:
2007-2-01   Seongbae Park [EMAIL PROTECTED]

PR inline-asm/28686
* global.c (global_alloc): Add mising initialization of
ELIMINABLE_REGSET.

2007-02-01  Roger Sayle  [EMAIL PROTECTED]



Modified:
trunk/gcc/ChangeLog
trunk/gcc/global.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686



[Bug inline-asm/28686] ebp from clobber list used as operand

2007-01-30 Thread spark at gcc dot gnu dot org


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC|seongbae dot park at gmail  |
   |dot com |
 AssignedTo|unassigned at gcc dot gnu   |spark at gcc dot gnu dot org
   |dot org |
 Status|NEW |ASSIGNED
   Last reconfirmed|2007-01-30 19:09:28 |2007-01-30 21:43:48
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686



[Bug inline-asm/28686] ebp from clobber list used as operand

2007-01-30 Thread spark at gcc dot gnu dot org


--- Comment #4 from spark at gcc dot gnu dot org  2007-01-31 00:28 ---
Looks like eliminable_regset is not cleared per every invocation of
global_alloc, making stale bits from the compilation of previous function hang
around - hence a presence of a previous function makes difference. 
Following patch seems to fix -O2 problem.
I'm now on to -O1 and -O0 issues.

Index: global.c
===
--- global.c(revision 121353)
+++ global.c(working copy)
@@ -354,6 +354,7 @@ global_alloc (void)
  are safe to use only within a basic block.  */

   CLEAR_HARD_REG_SET (no_global_alloc_regs);
+  CLEAR_HARD_REG_SET (eliminable_regset);

   /* Build the regset of all eliminable registers and show we can't use those
  that we already know won't be eliminated.  */
@@ -2548,4 +2549,3 @@ struct tree_opt_pass pass_global_alloc =
   TODO_ggc_collect, /* todo_flags_finish */
   'g'   /* letter */
 };
-


-- 

spark at gcc dot gnu dot org changed:

   What|Removed |Added

 CC||spark at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28686