[Bug middle-end/41343] New: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[Bug middle-end/41343] New: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[froydnj at gcc dot gnu dot org]

When compiling the attached file as:

powerpc-linux-gnu-gcc dosincos.i -g -O2 -std=gnu99 -fgnu89-inline
-fmerge-all-constants

The memory use of GCC balloons to 4GB+.  I have a low ulimit on my machine, so
I don't know whether leaving it alone with more memory would let the
compilation finish.  Using -fdump-tree-all-details indicates that things die
somewhere in the inline_param3 pass.

Discussion on IRC demonstrates the same behavior with a cross compiler from
x86-64, with memory usage up to 12GB without finishing.


-- 
           Summary: sysdeps/ieee754/dbl-64/dosincos.c from glibc causes
                    excessive memory use
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: froydnj at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc-linux-gnu


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[froydnj at gcc dot gnu dot org]

------- Comment #1 from froydnj at gcc dot gnu dot org  2009-09-12 04:05 -------
Created an attachment (id=18571)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18571&action=view)
testcase


-- 


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 794 bytes --]



------- Comment #2 from aoliva at gcc dot gnu dot org  2009-09-12 06:39 -------
Created an attachment (id=18572)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18572&action=view)
patch that might help alleviate the problem

This patch helped me save a lot of memory on another PPC testcase that involved
lots of expressions with equivalent values, which causes “interesting“ behavior
in var-tracking/cselib, generating a lot of RTL junk.  From your description,
it's not clear that it's the same problem, but I thought I'd post the
(unpolished) patch anyway, because a proper algorithmic fix to var-tracking
will take longer.  Even more so because I'm away for a week, starting today.  I
hope this helps.  Please let me know.


-- 


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[ramana at gcc dot gnu dot org]

------- Comment #3 from ramana at gcc dot gnu dot org  2009-09-12 06:48 -------
*** Bug 41342 has been marked as a duplicate of this bug. ***


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ramana at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[ramana at gcc dot gnu dot org]

------- Comment #4 from ramana at gcc dot gnu dot org  2009-09-12 06:49 -------
This test case fails for an arm-linux-gnueabi target as well.


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|powerpc-linux-gnu           |powerpc-linux-gnu, arm-
                   |                            |linux-gnueabi


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

[Bug middle-end/41343] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[ramana at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1361 bytes --]



------- Comment #5 from ramana at gcc dot gnu dot org  2009-09-12 07:05 -------
(In reply to comment #2)
> Created an attachment (id=18572)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18572&action=view) [edit]
> patch that might help alleviate the problem
> 
> This patch helped me save a lot of memory on another PPC testcase that involved
> lots of expressions with equivalent values, which causes “interesting“ behavior
> in var-tracking/cselib, generating a lot of RTL junk.  From your description,
> it's not clear that it's the same problem, but I thought I'd post the
> (unpolished) patch anyway, because a proper algorithmic fix to var-tracking
> will take longer.  Even more so because I'm away for a week, starting today.  I
> hope this helps.  Please let me know.
> 

The patch didn't apply cleanly for me and didn't make any noticeable difference
on arm-*eabi configuratons for me.


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-09-12 07:05:26
               date|                            |


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-09-12 11:56 -------
We should definitely limit the size of expressions we store in debug
stmts/insns.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |memory-hog
            Summary|sysdeps/ieee754/dbl-        |[4.5 Regression]
                   |64/dosincos.c from glibc    |sysdeps/ieee754/dbl-
                   |causes excessive memory use |64/dosincos.c from glibc
                   |                            |causes excessive memory use
   Target Milestone|---                         |4.5.0


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2009-09-12 12:10 -------
Because I can easily cause exponential growth with them:

void foo (int i)
{
  int i1 = i + i;
  int i2 = i1 + i1;
  int i3 = i2 + i2;
  int i4 = i3 + i3;
}

will generate

  # DEBUG i1 => i_1(D) + i_1(D)
  # DEBUG i2 => (i_1(D) + i_1(D)) + (i_1(D) + i_1(D))
  # DEBUG i3 => ((i_1(D) + i_1(D)) + (i_1(D) + i_1(D))) + ((i_1(D) + i_1(D)) +
(i_1(D) + i_1(D)))
  # DEBUG i4 => (((i_1(D) + i_1(D)) + (i_1(D) + i_1(D))) + ((i_1(D) + i_1(D)) +
(i_1(D) + i_1(D)))) + (((i_1(D) + i_1(D)) + (i_1(D) + i_1(D))) + ((i_1(D) +
i_1(D)) + (i_1(D) + i_1(D))))

Testcase:

#define X(new,old) int i ## new = i ## old + i ## old;
#define Y(pfx) X(pfx ## 1, pfx) \
  X(pfx ## 2, pfx ## 1) \
  X(pfx ## 3, pfx ## 2) \
  X(pfx ## 4, pfx ## 3) \
  X(pfx ## 5, pfx ## 4) \
  X(pfx ## 6, pfx ## 5) \
  X(pfx ## 7, pfx ## 6) \
  X(pfx ## 8, pfx ## 7) \
  X(pfx ## 9, pfx ## 8)

void foo (int i1)
{
  Y(1)
  Y(11)
  Y(111)
}


-- 


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2009-09-12 12:11 -------
We should be able to refer to previous debug insn/stmt vars instead of blindly
propagating all RHSs.


-- 


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[jakub at gcc dot gnu dot org]

------- Comment #9 from jakub at gcc dot gnu dot org  2009-09-14 15:04 -------
Limiting the size of the debug_stmt/debug_insn expression is certainly
desirable, having it unbounded is bad.  The question is what to do if the size
grows too much.  One possibility is dropping them to the floor, another one
would be to have a way to refer to other vars that are already tracked at the
current spot.  In debug info we could use DW_OP_call{2,4} to refer to those
DIEs' DW_AT_location, but AFAIK gdb doesn't handle those 2 yet.


-- 


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2009-09-14 16:13 -------
The simplest thing may be to disallow extra propagations, like from

 D.1234_2 = i0_1 + i0_1;
 # DEBUG i1 => D.1234_2

to

 # DEBUG i1 => i0 + i0

where dropping from i0_1 to i0 if more propagations would cause extra growth
and i0 is a user variable.

Of course a little more fancy.  In fact always stopping the propagation
if we get a user var should work as well as we'd have a proper debug
stmt for them anyway.  No?


-- 


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]



------- Comment #11 from aoliva at gcc dot gnu dot org  2009-09-15 04:17 -------
Referencing plain variable names in debug stmts is probably not a good idea, I
think it's too fragile.  However, arranging for SSA defs that would have been
propagated into debug stmts to be instead replaced with other debug stmts that
bind to “temps” appears to be pretty easy to introduce.  I'm (slowly, on the
road) working on a patch to do just that.

So instead of

# DEBUG i2 => ((i_1(D) + i_1(D)) + (i_1(D) + i_1(D))

we'll have

# DEBUG DT.0 => (i_1(D) + i_1(D))
# DEBUG i2 => DT.0 + DT.0

these debug temps, if introduced as a different kind of “declaration”, with its
own uid counter, won't interfere with regular declarations UIDs, which affect
codegen.  They can be expanded and linked to a new RTL form, that links back to
the tree form, so that the new RTL form can be used in RTL expressions, while
the VAR_LOCATION still holds the tree form, and then var-tracking generates a
value for the RTL expression, and voila :-)

The only case of loss of debug info I can think of is if the block containing a
debug bind stmt for one of these temps is removed, but a subsequent block that
would require the debug bind stmt isn't.  I don't think this should happen in
general (it would be non-SSA), but I haven't quite thought it through.  We'll
see...


-- 


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2009-09-15 09:02 -------
Why do you think refering to other debug stmts decl is not a good idea?  I
was thinking of simplifying propagation into debug stmts by simply replacing
all uses of a to-become dead SSA name with a non-artificial decl with its
underlying declaration.  So,

 i_1 = j_2 + k_3;
 # DEBUG i <= i_1
 # DEBUG foo <= i_1 + 1

on removing i_1 becomes

 # DEBUG i <= j_1 + k_3
 # DEBUG foo <= i + 1

based on the fact that we better had a debug stmt for i already.

In fact I can't see how this is different from what you propose.  And in
fact your proposal effectively would do

 # DEBUG tmp0 <= j_1 + k_3
 # DEBUG i <= tmp0
 # DEBUG foo <= tmp0 + 1

effectively adding a new debug stmt for each regular stmt you remove.

I don't think that's going to fly.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[jakub at gcc dot gnu dot org]

------- Comment #13 from jakub at gcc dot gnu dot org  2009-09-15 09:18 -------
For dwarf2out.c, it is IMHO desirable to be able to find out the original decls
which you refer to, rather than have some artificial ones.  Otherwise for
DW_OP_call{2,4} you'd have to create artificial variables in the debug info and
refer to them.  dwarf2out.c then can decide whether the location is simple
enough to inline its location expression, or is too complex and use
DW_OP_call{2,4} in that case.


-- 


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1


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

[Bug middle-end/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[jakub at gcc dot gnu dot org]

------- Comment #14 from jakub at gcc dot gnu dot org  2009-09-22 12:13 -------
Correction - artificial variables aren't needed, DW_TAG_dwarf_procedure with
just DW_AT_location with the expression or loclist is enough.
That's BTW something that a dwarf compactor could do - look at dwarf
expressions in DW_AT_location attributes and .debug_loc, see if there are
subexpressions that occur frequently and big enough that replacing them with 3
byte DW_OP_call2 <ref2> would be worthwhile, for those add
DW_TAG_dwarf_procedure at some low DIE offset (< 64KB into .debug_info).  GCC
could do that too of course, perhaps as a special pass over the debug info
before sizing it.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |roland at redhat dot com


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |aoliva at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
          Component|middle-end                  |debug


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

------- Comment #15 from aoliva at gcc dot gnu dot org  2009-09-22 19:03 -------
(In reply to comment #12)
> Why do you think refering to other debug stmts decl is not a good idea?

Because referring to decls already has a well-defined meaning in debug stmts,
and that meaning refers to a run-time value/location arbitrarily assigned the
name of the variable, rather than to the source-level value of the variable. 
These values may very well be different, especially if optimizations coalesced
multiple variables into a single run-time location, and we move the references
across modifications of the run-time location.

This would get very messy in RTL, although it may not be immediately apparent
in gimple, and it might even appear to work for trivial cases.  But once the
ambiguity hits, you lose.


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[matz at gcc dot gnu dot org]

------- Comment #16 from matz at gcc dot gnu dot org  2009-10-03 23:18 -------
Created an attachment (id=18700)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18700&action=view)
pr41264-test.c

Hmm, seems I used the wrong bug report to assign a nicer testcase.  Here
the comment and testcase I initially added to PR41264:
---
Found a nice testcase for exponential explosion.  It's reduced from tree.c
(make_vector_type) when building with -fprofile-generate.  The testcase needs
simply "-O2 -g" and takes a ridiculous amount of > 4GB RAM.
It's the tree-ssa-sink pass that triggers this in this case (with slight
variations in the testcase I can also make it blow up in RTL fwprop).

This means btw. that profiledbootstrap is broken.
---
Compile this with
% ./cc1 -O2 -g pr41264-test.c
and cry.


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

------- Comment #17 from aoliva at gcc dot gnu dot org  2009-10-06 04:38 -------
This patch fixes the problem:
http://gcc.gnu.org/ml/gcc-patches/2009-10/msg00112.html


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2009-10-07 21:32 -------
*** Bug 41625 has been marked as a duplicate of this bug. ***


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |denis dot onischenko at
                   |                            |gmail dot com


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

------- Comment #19 from aoliva at gcc dot gnu dot org  2009-10-12 18:59 -------
Subject: Bug 41343

Author: aoliva
Date: Mon Oct 12 18:58:38 2009
New Revision: 152681

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152681
Log:
gcc/ChangeLog:
PR debug/41343
PR debug/41447
PR debug/41264
PR debug/41338
* tree.def (DEBUG_EXPR_DECL): New.
* rtl.def (DEBUG_EXPR): New.
* gengtype.c (adjust_field_rtx_def): Handle it.
* tree-ssa.c (propagate_var_def_into_debug_stmts): Rename to...
(insert_debug_temp_for_var_def): ... this.  Drop support for
moving.  Take iterator for def stmt; insert debug stmt before it.
Scan early for use count and kind in debug stmts.
(propagate_defs_into_debug_stmts): Rename to...
(insert_debug_temps_for_defs): ... this.  Likewise.
* tree.h (DEBUG_TEMP_UID): New.
* tree.c (next_debug_decl_uid): New.
(make_node_stat): Count debug decls separately.
(copy_node_stat): Likewise.
* cfgexpand.c (expand_debug_expr): Handle DEBUG_EXPR_DECL.
* var-tracking.c (dv_is_decl_p): Recognize it.
(VALUE_RECURSED_INTO): Apply to DEBUG_EXPRs too.
(track_expr_p): Track expanded DEBUG_EXPR_DECLs.
(vt_expand_loc_callback): Expand DEBUG_EXPRs.
(emit_note_insn_var_location): Don't emit notes for DEBUG_EXPR_DECLs.
* cselib.c (rtx_equal_for_cselib_p): Handle DEBUG_EXPR.
(cselib_hash_rtx): Likewise.
(cselib_expand_value_rtx_1): Use callback for DEBUG_EXPR.
* tree-ssa-operands.c (get_expr_operands): Skip DEBUG_EXPR_DECLs in
debug bind stmts.
* emit-rtl.c (verify_rtx_sharing): Handle DEBUG_EXPR and VALUE.
(copy_rtx_if_shared_1, reset_used_flags, set_used_flags): Likewise.
* rtl.c (copy_rtx): Likewise.
(rtx_equal_p_cb, rtx_equal_p): Handle DEBUG_EXPR.
* print-rtl.c (print_rtx): Likewise.
* sched-vis.c (print_value): Likewise.
(print_insn): Handle DEBUG_EXPR_DECL.
* tree-dump.c (dequeue_and_dump): Likewise.
* tree-pretty-print.c (dump_decl_name, dump_generic_node): Likewise.
* gimple-iterator (gsi_replace): Check for same lhs.
(gsi_remove): Insert debug temps.
* tree-ssa-loop-im.c (rewrite_reciprocal): Replace with same lhs.
(move_computations_stmt): Drop explicit propagation into debug stmts.
(rewrite_bittest): Likewise.  Use gsi_remove for propagation.
* tree-ssa-reassoc.c (rewrite_expr_tree, linearize_expr): Likewise.
* tree-ssa-sink.c (statement_sink_location): Likewise.
* tree-ssa-forwprop (forward_propagate_addr_expr): Likewise.
* tree-ssanames.c (release_ssa_name): Adjust for rename.
* tree-flow.h: Likewise.
* tree-ssa-dce.c (mark_stmt_if_obviously_necessary): Don't mark
debug temps without values.
(eliminate_unnecessary_stmts): Don't discard just-inserted
debug stmts.
gcc/testsuite/ChangeLog:
PR debug/41343
PR debug/41447
PR debug/41264
PR debug/41338
* gcc.dg/guality/pr41447-1.c: New.
* gcc.dg/debug/pr41264-1.c: New.
* gcc.dg/debug/pr41343-1.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/debug/pr41264-1.c
    trunk/gcc/testsuite/gcc.dg/debug/pr41343-1.c
    trunk/gcc/testsuite/gcc.dg/guality/pr41447-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/cselib.c
    trunk/gcc/emit-rtl.c
    trunk/gcc/gengtype.c
    trunk/gcc/gimple-iterator.c
    trunk/gcc/print-rtl.c
    trunk/gcc/rtl.c
    trunk/gcc/rtl.def
    trunk/gcc/sched-vis.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-dump.c
    trunk/gcc/tree-flow.h
    trunk/gcc/tree-pretty-print.c
    trunk/gcc/tree-ssa-dce.c
    trunk/gcc/tree-ssa-forwprop.c
    trunk/gcc/tree-ssa-loop-im.c
    trunk/gcc/tree-ssa-operands.c
    trunk/gcc/tree-ssa-reassoc.c
    trunk/gcc/tree-ssa-sink.c
    trunk/gcc/tree-ssa.c
    trunk/gcc/tree-ssanames.c
    trunk/gcc/tree.c
    trunk/gcc/tree.def
    trunk/gcc/tree.h
    trunk/gcc/var-tracking.c


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

------- Comment #20 from aoliva at gcc dot gnu dot org  2009-10-12 19:58 -------
Fixed


-- 

aoliva at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[aoliva at gcc dot gnu dot org]

------- Comment #21 from aoliva at gcc dot gnu dot org  2009-10-14 05:01 -------
Subject: Bug 41343

Author: aoliva
Date: Wed Oct 14 05:01:24 2009
New Revision: 152749

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152749
Log:
PR debug/41343
PR debug/41447
PR debug/41264
PR debug/41338
* tree.c (tree_node_structure_for_code): DEBUG_EXPR_DECL uses
decl with rtl.
(tree_code_size): Likewise.

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


-- 


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[paolo dot carlini at oracle dot com]

------- Comment #22 from paolo dot carlini at oracle dot com  2009-11-11 23:40 -------
*** Bug 42012 has been marked as a duplicate of this bug. ***


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aleppos at hotmail dot com


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

[Bug debug/41343] [4.5 Regression] sysdeps/ieee754/dbl-64/dosincos.c from glibc causes excessive memory use

[jan dot kratochvil at redhat dot com]

------- Comment #23 from jan dot kratochvil at redhat dot com  2010-06-07 20:03 -------
(In reply to comment #9)
> In debug info we could use DW_OP_call{2,4} to refer to those
> DIEs' DW_AT_location, but AFAIK gdb doesn't handle those 2 yet.

FYI FSF GDB HEAD supports them now:
http://sourceware.org/bugzilla/show_bug.cgi?id=10640

DW_OP_call_ref is still not supported, though:
http://sourceware.org/bugzilla/show_bug.cgi?id=11674


-- 


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