[Bug debug/58315] New: [4.8/4.9 Regression] Excessive memory use with -g

[Bug debug/58315] New: [4.8/4.9 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

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

            Bug ID: 58315
           Summary: [4.8/4.9 Regression] Excessive memory use with -g
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Keywords: memory-hog
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org

Compiling the PPL testsuite, specifically MIP_Problem/mipproblem1.cc, with
-O2 -g makes GCC use nearly 6GB of memory (followed by GAS needing 6.5GB
of memory to assemble the result).

Dropping -g results in instant gratification.

[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 30747
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30747&action=edit
testcase

[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.2

[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Unsurprisingly the culprit is var-tracking.  Disabling it gets memory use
down to 250MB.

[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
See http://sourceware.org/bugzilla/show_bug.cgi?id=15930 for the as bugreport.

[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.2                       |4.8.3

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.2 has been released.

[Bug debug/58315] [4.8/4.9 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-22
     Ever confirmed|0                           |1

[Bug debug/58315] [4.8/4.9/4.10 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.3                       |4.8.4

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 4.8.3 is being released, adjusting target milestone.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.8.4 has been released.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |aldyh at gcc dot gnu.org

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I'm sure I'll regret it, but... I'll take a look.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
On mainline, with ./cc1plus -O2 -g, I approximately see a maximum of:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND    
 9204 aldyh     20   0  827704 697088  25036 R  99.7  4.3   4:35.01 cc1plus

which, though large, is not anywhere close to 6GB.  If I'm reading this right,
it seems like 697megs.

Var tracking seems to be resetting itself after this 697meg usage, and
finishing in a sensible manner:

b.ii: In function ‘bool {anonymous}::test03()’:
b.ii:84991:1: note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without

With -fno-var-tracking, I see a maximum of:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 9880 aldyh     20   0  478588 347524  24976 R  99.3  2.2   3:14.13 cc1plus

So, with var tracking we use 697MB, whereas without we use 478MB, both
relatively reasonable IMO.  The compilation does take a while on my i7 2.9GHz
(4:35 and 3:14 respectively), but all within (annoying) reason.

Richard, can we close this PR?
>From gcc-bugs-return-477853-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 19 23:12:26 2015
Return-Path: <gcc-bugs-return-477853-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4080 invoked by alias); 19 Feb 2015 23:12:25 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4028 invoked by uid 48); 19 Feb 2015 23:12:22 -0000
From: "richard-gccbugzilla at metafoo dot co.uk" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62116] Allowing redeclaration of global variable x using ::x
Date: Thu, 19 Feb 2015 23:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: richard-gccbugzilla at metafoo dot co.uk
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-62116-4-3y1F4ghIbq@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62116-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62116-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg02186.txt.bz2
Content-length: 664

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb116

Richard Smith <richard-gccbugzilla at metafoo dot co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard-gccbugzilla@metafoo
                   |                            |.co.uk

--- Comment #3 from Richard Smith <richard-gccbugzilla at metafoo dot co.uk> ---
This is a GCC bug (or extension). Expression / declaration disambiguation is
purely syntactic, and 'int(::x);' conforms to the grammar for a
simple-declaration.

I've also reported the bug to EDG.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |x86_64-*-*
             Status|WAITING                     |NEW
      Known to work|                            |4.7.4

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, I still see >2GB of memory - just checked with ulimit -v 2000000 where 4.7
succeeds but 4.8, 4.9 and 5 (r220758).

Thus, re-confirmed.  Without var-tracking GCC 5 tops out at ~400MB.

I don't get the following note:

b.ii: In function ‘bool {anonymous}::test03()’:
b.ii:84991:1: note: variable tracking size limit exceeded with
-fvar-tracking-assignments, retrying without

did you use some patched GCC with lower limits?
>From gcc-bugs-return-477884-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 20 08:23:59 2015
Return-Path: <gcc-bugs-return-477884-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31307 invoked by alias); 20 Feb 2015 08:23:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 31236 invoked by uid 48); 20 Feb 2015 08:23:56 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/63958] [5 Regression] bootstrap failure in the sanitizer libs on sparc-linux-gnu
Date: Fri, 20 Feb 2015 08:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63958-4-auP9pP5Jcp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63958-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63958-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg02217.txt.bz2
Content-length: 270

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc958

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The r216224 change apparently applies cleanly to the current sources, does it
fix all the sparc*-linux build issues?  My SPARC box is long time dead...

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #10 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #9)
> Hmm, I still see >2GB of memory - just checked with ulimit -v 2000000 where
> 4.7
> succeeds but 4.8, 4.9 and 5 (r220758).
> 
> Thus, re-confirmed.  Without var-tracking GCC 5 tops out at ~400MB.
> 
> I don't get the following note:
> 
> b.ii: In function ‘bool {anonymous}::test03()’:
> b.ii:84991:1: note: variable tracking size limit exceeded with
> -fvar-tracking-assignments, retrying without
> 
> did you use some patched GCC with lower limits?

I am using mainline as of two days ago, but in the interest of full-disclosure,
I can't get your testcase to compile unmodified:

$ ./cc1plus mipproblem1.ii -quiet
In file included from ../../src/algorithms.hh:28:0,
                 from ../../src/ppl_include_files.hh:14,
                 from ../../src/ppl_header.hh:38,
                 from ../../tests/ppl_test.hh:27,
                 from mipproblem1.cc:24:
../../src/Pointset_Powerset.defs.hh:1398:37: error: redeclaration of
‘template<class QH>
Parma_Polyhedra_Library::Pointset_Powerset<PSET>::Pointset_Powerset(const
Parma_Polyhedra_Library::Pointset_Powerset<QH>&,
Parma_Polyhedra_Library::Complexity_Class) [with QH = QH; PSET =
Parma_Polyhedra_Library::NNC_Polyhedron]’ may not have default arguments
[-fpermissive]

The above corresponds to the following code in
ppl/src/Pointset_Powerset_defs.hh, which I have had to comment out:

// CHECKME: according to the Intel compiler, the declaration of the
// following specialization (of the class template parameter) should come
// before the declaration of the corresponding full specialization
// (where the member template parameter is specialized too).
template <>
template <typename QH>
Pointset_Powerset<NNC_Polyhedron>
::Pointset_Powerset(const Pointset_Powerset<QH>& y,
                    Complexity_Class);

Interestingly, the current Fedora package for ppl has a patch for this
particular line:

+#if __GNUC__ < 5
 // CHECKME: according to the Intel compiler, the declaration of the
 // following specialization (of the class template parameter) should come
 // before the declaration of the corresponding full specialization
@@ -1400,6 +1401,7 @@ template <typename QH>
 Pointset_Powerset<NNC_Polyhedron>
 ::Pointset_Powerset(const Pointset_Powerset<QH>& y,
                     Complexity_Class);
+#endif

Is your attached testcase ./cc1plus-ing unmodified?
>From gcc-bugs-return-477965-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 20 16:06:00 2015
Return-Path: <gcc-bugs-return-477965-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9962 invoked by alias); 20 Feb 2015 16:06:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9906 invoked by uid 48); 20 Feb 2015 16:05:57 -0000
From: "code at leeclagett dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65142] New: std::random_device Ignores Read Return Code
Date: Fri, 20 Feb 2015 16:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: code at leeclagett dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-65142-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg02297.txt.bz2
Content-length: 653

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide142

            Bug ID: 65142
           Summary: std::random_device Ignores Read Return Code
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: code at leeclagett dot com

When std::random_device reads from the designated random file, it does not
check the return code from the read. libc++ throws an exception if 0 or less
bytes were read. Without this check, the returned value is completely or
partially unitialized.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #10)
> Is your attached testcase ./cc1plus-ing unmodified?

With -O2 -g -fpermissive, yes.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Just checked r220835 from today and it still takes more than 2GB of virtual
memory.  (the compiler has checking enabled, but I doubt that makes a
difference?)

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #13 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> Just checked r220835 from today and it still takes more than 2GB of virtual
> memory.  (the compiler has checking enabled, but I doubt that makes a
> difference?)

Ah!  Got it.  I was using ppl-1.1, which seemed like the last release on the
PPL site.  I have now reproduced with your testcase, and either removing the
offending line, or using -fpermissive.

I see the memory usage go gradually up to 500megs, and then explodes from then
on.

Will take a look.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aoliva at gcc dot gnu.org,
                   |                            |rth at gcc dot gnu.org

--- Comment #14 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
I'm not very familiar with the var tracking code, but one thing I see odd here
is a ton of similar var_location notes attached to each instruction (well, not
each instruction, but a lot of the instructions are affected while generating
code for test01, test02, test03, test04, etc).

I see an instruction like this:

(insn:TI 52195 52199 83288 6386 (set (mem/c:DI (plus:DI (reg/f:DI 6 bp)
                (const_int -25880 [0xffffffffffff9ae8])) [125 %sfp+-25864 S8
A64])
        (reg:DI 0 ax)) 89 {*movdi_internal}
     (expr_list:REG_DEAD (reg:DI 0 ax)
        (nil)))
(jump_insn 83288 52195 83289 6386 (set (pc)
        (label_ref 34659)) 653 {jump}
     (nil)
 -> 34659)

Followed by over 1000 var_location notes:

(note 11489581 83289 11489582 (var_location this(0x7fffe7223360)  (plus:DI
(reg/f:DI 6 bp)
    (const_int -21808 [0xffffffffffffaad0]))) NOTE_INSN_VAR_LOCATION)
(note 11489582 11489581 11489583 (var_location this(0x7fffe8d7dc60)  (plus:DI
(reg/f:DI 6 bp)
    (const_int -25200 [0xffffffffffff9d90]))) NOTE_INSN_VAR_LOCATION)
(note 11489583 11489582 11489584 (var_location this(0x7fffe72236c0)  (plus:DI
(reg/f:DI 6 bp)
    (const_int -21856 [0xffffffffffffaaa0]))) NOTE_INSN_VAR_LOCATION)
(note 11489584 11489583 11489585 (var_location this(0x7fffe7223bd0)  (plus:DI
(reg/f:DI 6 bp)
    (const_int -6576 [0xffffffffffffe650]))) NOTE_INSN_VAR_LOCATION)
(note 11489585 11489584 11489586 (var_location this(0x7fffe7223cf0)  (plus:DI
(reg/f:DI 6 bp)
    (const_int -21872 [0xffffffffffffaa90]))) NOTE_INSN_VAR_LOCATION)
(note 11489586 11489585 11489587 (var_location this(0x7fffe941e090)  (plus:DI
(reg/f:DI 6 bp)
    (const_int -25136 [0xffffffffffff9dd0]))) NOTE_INSN_VAR_LOCATION)

etc
etc etc
.

Notice all of them are the "this" pointer, but I have hacked the RTL dumping
code to also print the address of the DECL to show that every "this" is
actually a different instance.

This looks suspect.  Anyone have a clue, otherwise I'm going to continue
banging my head against a wall here?

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #15 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
And annoyingly, even stuff as repetitive like this (notice, the same exact `di'
register, no offset or anything):

(note 11470254 74094 11470255 6371 (var_location this(0x7fffeeac8bd0)  (reg:DI
5 di [17204])) NO
TE_INSN_VAR_LOCATION)
(note 11470255 11470254 11470256 6371 (var_location this(0x7fffe72233f0) 
(reg:DI 5 di [17204]))
 NOTE_INSN_VAR_LOCATION)
(note 11470256 11470255 11470257 6371 (var_location this(0x7fffe7223510) 
(reg:DI 5 di [17204]))
 NOTE_INSN_VAR_LOCATION)
(note 11470257 11470256 11470258 6371 (var_location this(0x7fffe7223a20) 
(reg:DI 5 di [17204]))
 NOTE_INSN_VAR_LOCATION)
(note 11470258 11470257 11470259 6371 (var_location this(0x7fffe7223ab0) 
(reg:DI 5 di [17204]))
 NOTE_INSN_VAR_LOCATION)
...
...
1300 more of these.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Aldy Hernandez <aldyh at gcc dot gnu.org> changed:

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

--- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Among other things (because I'm not 100% sure this is the only thing wrong
here) we seem to be generating and awful lot of GIMPLE_DEBUG statements, even
for intermediate values we will throw away.

I am not sure whether this is just a very inefficient testcase, a byproduct of
the way we expand expressions, or the myriad of DEBUG statements we create.

For instance, in a snippet of the testcase:

    Variable A(0);
    Variable B(1);
    Variable C(2);
    Variable D(3);
    Constraint_System cs;

    cs.insert(Coefficient("2251799813685248")*A
          >= Coefficient("-5895288448651847"));
    cs.insert(Coefficient("5895288437392848")*A
          + Coefficient("3643488632714799")*B
          - Coefficient("2251799813685248")*C
          >= Coefficient("-19077554137963492"));
    ...

...we create a temporary instance for each Coefficient constructor call, as
well as a temporary instance for the result of the '*' and '>=' operators, and
a temporary instance for the conversion of [ABC] to a Linear_Expression. 
Basically, we create temporary instances of every class we create along the way
(expected), but unfortunately we then create DEBUG statements for each
destructor call in each temporary variable that was created, particularly for
the `this' pointer which is quite useless for debugging IMO.

For instance, the result of the ">=" operator gets stored in D.166575, but as
you can see below, there are quite a few DEBUG statements for this temporary
which will never see the light of (debugging) day:

  D.166575 = Parma_Polyhedra_Library::operator>= (&D.166573, &D.166574);

  <bb 7>:
  Parma_Polyhedra_Library::Constraint_System::insert (&cs, &D.166575);

  <bb 8>:
  # DEBUG this => &D.166575
  # DEBUG D#21 => &D.166575.D.73843
  # DEBUG this => D#21
  # DEBUG D#19 => &D#21->D.67748
  # DEBUG this => D#19
  _1448 = &MEM[(struct Row *)&D.166575].D.66121;
  Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1448);

If you look at the "einline" tree dump, you can see numerous DEBUG statements
for each destructor call:

 MEM[(struct  &)&D.166591] ={v} {CLOBBER};
  # DEBUG <L0> => NULL
  MEM[(struct  &)&D.166591] ={v} {CLOBBER};
  # DEBUG <L0> => NULL
  MEM[(struct  &)&D.166591] ={v} {CLOBBER};
  # DEBUG <L0> => NULL
  D.166591 ={v} {CLOBBER};
  # DEBUG this => &D.166589
  # DEBUG D#20 => &D.166589.D.71066
  # DEBUG this => D#20
  # DEBUG D#19 => &D#20->D.67748
  # DEBUG this => D#19
  _1479 = &MEM[(struct Row *)&D.166589].D.66121;
  Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1479);

ad nauseum.

These DEBUG statements eventually end up as a multitude of VAR_LOCATION rtl
notes that take an awful lot of memory to process.  As I've said, I'm not 100%
this is the problem, but I'm quite suspect.

Also, it may not be the DEBUG statements at fault, but the inefficiency of the
testcase itself (creating all these objects), in which case, perhaps we could
notice this behavior at var-tracking time, and bail?  Though this sounds like a
kludge.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #17 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
BTW, if it isn't clear from the previous comment, the reason I believe this
test may be inefficient is because we have pages upon pages of:

    cs.insert(Coefficient("1125899906842624")*B
          >= Coefficient("-2947644227703623"));
    cs.insert(Coefficient("5895288459910846")*B
          + Coefficient("2251799813685248")*C
          + Coefficient("3643488630462999")*D
          >= Coefficient("-19077554198762088"));
    cs.insert(Coefficient("5895288457659046")*B
          + Coefficient("2251799813685248")*C
          - Coefficient("3643488628211199")*D
          >= Coefficient("-19077554189754888"));
    cs.insert(Coefficient("11790576915318092")*B
          - Coefficient("4503599627370496")*C
          + Coefficient("7286977269933197")*D
          >= Coefficient("-38155108393020576"));
     ...

...all creating temporary objects for each coefficient and factor.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #18 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Created attachment 34852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34852&action=edit
reduced and indented testcase

Memory explosion occurs while compiling test03() function.  Memory usage before
calling vt_find_locations is 382MB and after is 650MB.  Memory usage after
calling vt_emit_notes is 1322MB.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Generally, if the debug stmts are about different variables/parameters, then
supposedly they really shouldn't be useless, you really might be interested in
knowing at all times especially what this is, in the current inline function,
as well as when doing up in virtual backtraces, otherwise you really can't call
methods in the debugger etc.
If it is about debug stmts for the same variable without intervening other
stmts (so, effectively it is something you couldn't really inspect in the
debuggers), then it is something Alex planned in his papers for the future for
virtual stepping without really moving instruction pointers, but if Alex
doesn't plan to work on that in the near future, perhaps we should guarded by
some option perhaps DCE the for now useless debug stmts.  Similarly, if we
don't DCE debug stmts setting debug temporaries that aren't used by any debug
stmts, we perhaps should.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 23 Feb 2015, aldyh at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
> 
> Aldy Hernandez <aldyh at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |jason at gcc dot gnu.org,
>                    |                            |rguenth at gcc dot gnu.org
> 
> --- Comment #16 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
> Among other things (because I'm not 100% sure this is the only thing wrong
> here) we seem to be generating and awful lot of GIMPLE_DEBUG statements, even
> for intermediate values we will throw away.
> 
> I am not sure whether this is just a very inefficient testcase, a byproduct of
> the way we expand expressions, or the myriad of DEBUG statements we create.
> 
> For instance, in a snippet of the testcase:
> 
>     Variable A(0);
>     Variable B(1);
>     Variable C(2);
>     Variable D(3);
>     Constraint_System cs;
> 
>     cs.insert(Coefficient("2251799813685248")*A
>           >= Coefficient("-5895288448651847"));
>     cs.insert(Coefficient("5895288437392848")*A
>           + Coefficient("3643488632714799")*B
>           - Coefficient("2251799813685248")*C
>           >= Coefficient("-19077554137963492"));
>     ...
> 
> ...we create a temporary instance for each Coefficient constructor call, as
> well as a temporary instance for the result of the '*' and '>=' operators, and
> a temporary instance for the conversion of [ABC] to a Linear_Expression. 
> Basically, we create temporary instances of every class we create along the way
> (expected), but unfortunately we then create DEBUG statements for each
> destructor call in each temporary variable that was created, particularly for
> the `this' pointer which is quite useless for debugging IMO.
> 
> For instance, the result of the ">=" operator gets stored in D.166575, but as
> you can see below, there are quite a few DEBUG statements for this temporary
> which will never see the light of (debugging) day:
> 
>   D.166575 = Parma_Polyhedra_Library::operator>= (&D.166573, &D.166574);
> 
>   <bb 7>:
>   Parma_Polyhedra_Library::Constraint_System::insert (&cs, &D.166575);
> 
>   <bb 8>:
>   # DEBUG this => &D.166575
>   # DEBUG D#21 => &D.166575.D.73843
>   # DEBUG this => D#21
>   # DEBUG D#19 => &D#21->D.67748
>   # DEBUG this => D#19
>   _1448 = &MEM[(struct Row *)&D.166575].D.66121;
>   Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1448);
> 
> If you look at the "einline" tree dump, you can see numerous DEBUG statements
> for each destructor call:
> 
>  MEM[(struct  &)&D.166591] ={v} {CLOBBER};
>   # DEBUG <L0> => NULL
>   MEM[(struct  &)&D.166591] ={v} {CLOBBER};
>   # DEBUG <L0> => NULL
>   MEM[(struct  &)&D.166591] ={v} {CLOBBER};
>   # DEBUG <L0> => NULL
>   D.166591 ={v} {CLOBBER};
>   # DEBUG this => &D.166589
>   # DEBUG D#20 => &D.166589.D.71066
>   # DEBUG this => D#20
>   # DEBUG D#19 => &D#20->D.67748
>   # DEBUG this => D#19
>   _1479 = &MEM[(struct Row *)&D.166589].D.66121;
>   Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1479);
> 
> ad nauseum.
> 
> These DEBUG statements eventually end up as a multitude of VAR_LOCATION rtl
> notes that take an awful lot of memory to process.  As I've said, I'm not 100%
> this is the problem, but I'm quite suspect.

It's true that the temporary object D.166591 cannot be accessed from the
debugger (it has no name) but we still create debug stmts for its 
_address_ - to which the debugger can refer to via named 'this'
(from some inline code).

But yes, we have multiple such assignments to 'this' at the (possible
assembler) location of a single statement which of course doesn't help.

Thus we should DCE the debug stmt sequences between real stmts like

>   D.166591 ={v} {CLOBBER};
>   # DEBUG this => &D.166589
>   # DEBUG D#20 => &D.166589.D.71066
>   # DEBUG this => D#20
>   # DEBUG D#19 => &D#20->D.67748
>   # DEBUG this => D#19
>   _1479 = &MEM[(struct Row *)&D.166589].D.66121;

to the following at least ("DSE" actually, based on the actual
name of the LHS a debugger might use to refer to the variable)

>   D.166591 ={v} {CLOBBER};
>   # DEBUG D#20 => &D.166589.D.71066
>   # DEBUG D#19 => &D#20->D.67748
>   # DEBUG this => D#19
>   _1479 = &MEM[(struct Row *)&D.166589].D.66121;

As to "between stmts" that is because after each 'stepi' in the
debugger you reach a new state computed by var-tracking.  Intermediate
state-transitions are not interesting as long as you preserve the
"last" state before the next instruction.

Thus in reality you'd want to perform this DCE/DSE right before
var-tracking (or during the var-tracking insn scan phase)

> Also, it may not be the DEBUG statements at fault, but the inefficiency 
> of the testcase itself (creating all these objects), in which case, 
> perhaps we could notice this behavior at var-tracking time, and bail?  
> Though this sounds like a kludge.

Of course the issue is very large and repetitive functions.  Thus
another idea is to simply split up such functions.  If just by
making var-tracking work on SESE (or SEME) regions and dealing
with the boundaries conservatively.

Eventually this can be "hacked" by fake splitting/restoring the
CFG around vt_initialize/vt_find_locations/vt_finalize.  Maybe
easier than to make them work on a CFG region.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #21 from Aldy Hernandez <aldyh at redhat dot com> ---
On 02/24/2015 12:39 AM, rguenther at suse dot de wrote:

> But yes, we have multiple such assignments to 'this' at the (possible
> assembler) location of a single statement which of course doesn't help.
>
> Thus we should DCE the debug stmt sequences between real stmts like
>
>>    D.166591 ={v} {CLOBBER};
>>    # DEBUG this => &D.166589
>>    # DEBUG D#20 => &D.166589.D.71066
>>    # DEBUG this => D#20
>>    # DEBUG D#19 => &D#20->D.67748
>>    # DEBUG this => D#19
>>    _1479 = &MEM[(struct Row *)&D.166589].D.66121;
>
> to the following at least ("DSE" actually, based on the actual
> name of the LHS a debugger might use to refer to the variable)

Let me see if I understood this correctly.  We need a DSE/DCE pass right 
before var-tracking that would eliminate the redundant `this' statements 
right before a non debug statement.  So, for something like this:

   # DEBUG this => &cs
   # DEBUG D#61 => &cs.D.73561
   # DEBUG this => D#61
   # DEBUG topol => 0
   # DEBUG D#60 => &D#61->D.71953
   # DEBUG this => D#60
   # DEBUG D#59 => &D#60->rows
   # DEBUG this => D#59
   # DEBUG D#58 => &D#59->D.66859
   # DEBUG this => D#58
   # DEBUG D#57 => &D#58->_M_impl
   # DEBUG this => D#57
   # DEBUG this => D#57
   # DEBUG this => D#57
   MEM[(struct _Vector_impl *)&cs]._M_start = 0B;
   <other non DEBUG stmts>

   <bb 8>:
   # DEBUG this => &D.166575
   # DEBUG D#21 => &D.166575.D.73843
   # DEBUG this => D#21
   # DEBUG D#19 => &D#21->D.67748
   # DEBUG this => D#19
   _1448 = &MEM[(struct Row *)&D.166575].D.66121;
   Parma_Polyhedra_Library::Row_Impl_Handler::~Row_Impl_Handler (_1448);

...we would delete all the "DEBUG this" in the first batch with the 
exception of the last one (DEBUG this => D#57).  All the intervening 
"DEBUG D#[0-9][0-9]" statements would remain.  For the second batch, we 
would also delete all the "DEBUG this" statements except the last one 
(DEBUG this => D#19)?

Is this what you have in mind?

>
>>    D.166591 ={v} {CLOBBER};
>>    # DEBUG D#20 => &D.166589.D.71066
>>    # DEBUG D#19 => &D#20->D.67748
>>    # DEBUG this => D#19
>>    _1479 = &MEM[(struct Row *)&D.166589].D.66121;
>
> As to "between stmts" that is because after each 'stepi' in the
> debugger you reach a new state computed by var-tracking.  Intermediate
> state-transitions are not interesting as long as you preserve the
> "last" state before the next instruction.
>
> Thus in reality you'd want to perform this DCE/DSE right before
> var-tracking (or during the var-tracking insn scan phase)
>
>> Also, it may not be the DEBUG statements at fault, but the inefficiency
>> of the testcase itself (creating all these objects), in which case,
>> perhaps we could notice this behavior at var-tracking time, and bail?
>> Though this sounds like a kludge.
>
> Of course the issue is very large and repetitive functions.  Thus
> another idea is to simply split up such functions.  If just by
> making var-tracking work on SESE (or SEME) regions and dealing
> with the boundaries conservatively.
>
> Eventually this can be "hacked" by fake splitting/restoring the
> CFG around vt_initialize/vt_find_locations/vt_finalize.  Maybe
> easier than to make them work on a CFG region.

The DCE/DSE pass sounds more straightforward IMO, but I just don't want 
to deal with data flow equations ;-).

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #21)
> Let me see if I understood this correctly.  We need a DSE/DCE pass right 
> before var-tracking that would eliminate the redundant `this' statements 
> right before a non debug statement.  So, for something like this:

First of all, these are GIMPLE statements, so doing anything on them can't be
right before var-tracking, which is one of the last RTL passes.
That said, I very much doubt you can DCE much here, just use -fdump-tree-*-all
to see the uids of the this PARM_DECLs/VAR_DECLs, I bet most of them will be
different.
> 
>    # DEBUG this => &cs
>    # DEBUG D#61 => &cs.D.73561
>    # DEBUG this => D#61
>    # DEBUG topol => 0
>    # DEBUG D#60 => &D#61->D.71953
>    # DEBUG this => D#60
>    # DEBUG D#59 => &D#60->rows
>    # DEBUG this => D#59
>    # DEBUG D#58 => &D#59->D.66859
>    # DEBUG this => D#58
>    # DEBUG D#57 => &D#58->_M_impl
>    # DEBUG this => D#57
>    # DEBUG this => D#57
>    # DEBUG this => D#57
>    MEM[(struct _Vector_impl *)&cs]._M_start = 0B;
>    <other non DEBUG stmts>

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aldyh at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #23 from Aldy Hernandez <aldyh at redhat dot com> ---
On 02/24/2015 07:53 AM, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315
>
> --- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to Aldy Hernandez from comment #21)
>> Let me see if I understood this correctly.  We need a DSE/DCE pass right
>> before var-tracking that would eliminate the redundant `this' statements
>> right before a non debug statement.  So, for something like this:
>
> First of all, these are GIMPLE statements, so doing anything on them can't be
> right before var-tracking, which is one of the last RTL passes.

Sorry, what I should've said was doing it right before expand, or at a 
place where gimple still exists.

> That said, I very much doubt you can DCE much here, just use -fdump-tree-*-all
> to see the uids of the this PARM_DECLs/VAR_DECLs, I bet most of them will be
> different.

Absolutely, _all_ of them are different for that matter.  I think what 
Richi was saying was that we could do a DSE type pass but take 
intervening stores to a DEBUG statement that have the same LHS name a 
debugger would see, and remove them based on that.  So it wouldn't 
matter that we have different `this':

# DEBUG this (for type "class foo") => D.1234
# DEBUG this (for type "class bar") => D.5678
# DEBUG this (for type "class biz") => D.9012

The first two stores are useless because you wouldn't be able to access 
them from a debugger.  Although perhaps I am misunderstanding something 
(??).

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #24 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #23)
> Absolutely, _all_ of them are different for that matter.  I think what 
> Richi was saying was that we could do a DSE type pass but take 
> intervening stores to a DEBUG statement that have the same LHS name a 
> debugger would see, and remove them based on that.  So it wouldn't 
> matter that we have different `this':
> 
> # DEBUG this (for type "class foo") => D.1234
> # DEBUG this (for type "class bar") => D.5678
> # DEBUG this (for type "class biz") => D.9012
> 
> The first two stores are useless because you wouldn't be able to access 
> them from a debugger.  Although perhaps I am misunderstanding something 
> (??).

The question is why do you think you couldn't access them in the debugger.
For the problem of tracking values of variables not in the scope please read
the thread starting at https://gcc.gnu.org/ml/gcc-patches/2010-03/msg00960.html
If you are talking about GIMPLE, you have no way to know what scheduling and
many other passes will perform for code motions etc., so really knowing if
something is or is not in scope is ever orders of magnitude harder there.
If say some foo class method invokes bar class method which invokes biz class
method and all 3 are inlined, then you obviously can and want to access all 3
in the debugger at the same point.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|aldyh at gcc dot gnu.org           |aoliva at gcc dot gnu.org

--- Comment #25 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 34861
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34861&action=edit
vta-reset-inlined-vars-at-return-point.patch

Mine.  The debug stmts are fine, even their large quantity.  In fact, we need
*additional* debug stmts to fix the problem.

What's causing the excess memory use is that var-tracking spends a lot of time
recomputing locations for variables that have long ceased to exist, because
they were inlined from other functions that have already "returned".

Now, unlike local variables, that we might reasonably want to be able to access
throughout the function, inlined variables are not accessible in any reasonable
way once we "return" from the functions that define them.  So, I introduced
code to reset the binding of all inlined functions at point the call would have
returned to, so that var-tracking will stop computing locations for them at
that point.

This brings compile time down from 2 minutes to 45 seconds (35s without -g),
and it reduces the .s output by the compiler by two orders of magnitude, from
1.1G to 15M (2.6M without -g), and it shouldn't have any noticeable effect on
debug information.

Once regstrapping is done I'll submit it.  It might have a noticeable effect in
reducing the, erhm, debug info abstraction penalty in C++ programs, especially
those with long functions with lots of inlined calls.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #26 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
I had failed to measure peak memory use.  It went down from more than 4.8G to
less than 460M (vs 380MB without debug info).  Wheee!

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexandre Oliva from comment #26)
> I had failed to measure peak memory use.  It went down from more than 4.8G
> to less than 460M (vs 380MB without debug info).  Wheee!

Wheee!

Note that this is exactly what I had in mind (kind of) - we should "DCE"
debug stmts when at the given text address the debugger cannot refer to
the entity the debug stmt is for - for example if the current scope is
simply not nested inside of the scope the debug entity is for.

In theory remove_unused_locals could do that - in the walk over
have_local_clobbers remove all GIMPLE debug stmts that have an
unused BLOCK associated.  Note that we still won't remove the actual BLOCKs
as we keep BLOCKs live with associated user-vars (but no associated
statements),
see remove_unused_scope_block_p.  Still removing debug statements associated
with such block (well, rather debug stmts with a LHS which is associated with
an unused BLOCK... - which is not exactly the same) should be possible.
Of course this should be done on the RTL level close to var-tracking but
it might be what your patch ends up effectively doing as well.

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #28 from Jason Merrill <jason at gcc dot gnu.org> ---
Author: jason
Date: Wed Feb 25 15:49:34 2015
New Revision: 220974

URL: https://gcc.gnu.org/viewcvs?rev=220974&root=gcc&view=rev
Log:
    PR debug/58315
    * decl.c (start_preparsed_function): Use create_artificial_label
    for cdtor_label.

Added:
    trunk/gcc/testsuite/g++.dg/tree-ssa/deleted-label1.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/decl.c

[Bug debug/58315] [4.8/4.9/5/6 Regression] Excessive memory use with -g

[redflames1003 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Christopher Torres <redflames1003 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redflames1003 at gmail dot com

--- Comment #29 from Christopher Torres <redflames1003 at gmail dot com> ---
(In reply to Jason Merrill from comment #28)
> Author: jason
> Date: Wed Feb 25 15:49:34 2015
> New Revision: 220974
> 
> URL: https://gcc.gnu.org/viewcvs?rev=220974&root=gcc&view=rev
> Log:
> 	PR debug/58315
> 	* decl.c (start_preparsed_function): Use create_artificial_label
> 	for cdtor_label.
> 
> Added:
>     trunk/gcc/testsuite/g++.dg/tree-ssa/deleted-label1.C
> Modified:
>     trunk/gcc/cp/ChangeLog
>     trunk/gcc/cp/decl.c


I also am looking for a fix for this issue. Compile times are at least x2
longer then before when I updated from an older version (from 30-40 minutes to
over 1 1/2 hours).

Is there any status updates on this issue? Does this effectively do what
Alexandre Oliva's patch does?
>From gcc-bugs-return-487414-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 27 15:36:43 2015
Return-Path: <gcc-bugs-return-487414-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1106 invoked by alias); 27 May 2015 15:36:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 1081 invoked by uid 48); 27 May 2015 15:36:39 -0000
From: "gerhard.steinmetz.fortran@t-online.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/66311] [5 Regression] Problems with some integer(16) values
Date: Wed, 27 May 2015 15:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gerhard.steinmetz.fortran@t-online.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66311-4-PYiBnzk8Vs@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66311-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66311-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-05/txt/msg02254.txt.bz2
Content-length: 960

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf311

--- Comment #1 from Gerhard Steinmetz <gerhard.steinmetz.fortran@t-online.de> ---
Of course, some computations are wrong, too.

For example :

   program p
      integer(8), parameter :: z = huge(1_8)
      print *, 2_16 * z
      print *, 2 * int(z, 16)
      print *, 2_16 * int(z, 16)
      print *, int(2, 16) * int(z, 16)
   end


Result with gfortran 5.1.1 :

 -2
 -2
 -2
 -2

Result with gfortran 4.9.0 and 4.8.3 :

 18446744073709551614
 18446744073709551614
 18446744073709551614
 18446744073709551614


---

Or this variation :

   program p
      integer(16), parameter :: z = huge(1_8)
      print *, 2_16 * z
      print *, 2 * int(z, 16)
      print *, 2_16 * int(z, 16)
      print *, int(2, 16) * int(z, 16)
   end

Result with gfortran 5.1.1 :

 -2
 -2
 -2
 -2

Result with gfortran 4.9.0 and 4.8.3 :

 18446744073709551614
 18446744073709551614
 18446744073709551614
 18446744073709551614

[Bug debug/58315] [4.8/4.9/5/6 Regression] Excessive memory use with -g

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #30 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Christopher Torres from comment #29)
> > URL: https://gcc.gnu.org/viewcvs?rev=220974&root=gcc&view=rev
> 
> Is there any status updates on this issue? Does this effectively do what
> Alexandre Oliva's patch does?

No, my patch was for a separate, smaller issue that was noticed while
investigating this bug report.

It looks like Alex's patch was being discussed on gcc-patches a couple of
months ago but fell by the wayside; seems a ping would be in order.

[Bug debug/58315] [4.8/4.9/5/6 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #31 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Author: aoliva
Date: Tue Jun  9 05:05:12 2015
New Revision: 224261

URL: https://gcc.gnu.org/viewcvs?rev=224261&root=gcc&view=rev
Log:
Reset inlined debug variables at the end of the inlined function

for  gcc/ChangeLog

        PR debug/58315
        * tree-inline.c (reset_debug_binding): New.
        (reset_debug_bindings): Likewise.
        (expand_call_inline): Call it.

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

[Bug debug/58315] [4.8/4.9/5/6 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

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

--- Comment #32 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Fixed

[Bug debug/58315] [4.8/4.9/5 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |ASSIGNED
         Resolution|FIXED                       |---
   Target Milestone|4.8.5                       |5.2
            Summary|[4.8/4.9/5/6 Regression]    |[4.8/4.9/5 Regression]
                   |Excessive memory use with   |Excessive memory use with
                   |-g                          |-g

--- Comment #33 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Err, this is only fixed in the trunk so far.  It's approved for 5.2 too, after
some time, if no issues pop up.  So, reopening.

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[redflames1003 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #35 from Christopher Torres <redflames1003 at gmail dot com> ---
(In reply to Alexandre Oliva from comment #33)
> Err, this is only fixed in the trunk so far.  It's approved for 5.2 too,
> after some time, if no issues pop up.  So, reopening.

Hey Alexandre,

I was wondering if it would be possible to get a patch for the 4.9 branch,
specifically 4.9.2. I tried applying the patch you posed here but I was unable
to cleanly compile due to errors. id->call_stmt and id->retbnd are not defined
in the struct.

We want to have this fix but are unable to upgrade to the latest due to the
size of our project.

Thanks,

Chris

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #36 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Created attachment 36472
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36472&action=edit
backported patch for the 4.9 branch

Chris,

retbnd is of no concern, nothing equivalent existed back then.

call_stmt was called gimple_call.

Here's a backported patch, barely tested.  Please let me know how it goes for
you.

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #37 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Author: aoliva
Date: Sat Oct 10 12:05:56 2015
New Revision: 228674

URL: https://gcc.gnu.org/viewcvs?rev=228674&root=gcc&view=rev
Log:
Reset inlined debug variables at the end of the inlined function

for  gcc/ChangeLog

        PR debug/58315
        * tree-inline.c (reset_debug_binding): New.
        (reset_debug_bindings): Likewise.
        (expand_call_inline): Call it.

Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/tree-inline.c

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[aoliva at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

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

--- Comment #38 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
I've finally installed the patch in the gcc-5-branch too.

[Bug debug/58315] [4.9/5 Regression] Excessive memory use with -g

[redflames1003 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58315

--- Comment #39 from Christopher Torres <redflames1003 at gmail dot com> ---
(In reply to Alexandre Oliva from comment #36)
> Created attachment 36472 [details]
> backported patch for the 4.9 branch
> 
> Chris,
> 
> retbnd is of no concern, nothing equivalent existed back then.
> 
> call_stmt was called gimple_call.
> 
> Here's a backported patch, barely tested.  Please let me know how it goes
> for you.

Thank you. Looking at the diff it doesn't look like this will actually compile
since redbnd and call_stmt is still in there. Did you maybe upload the wrong
patch file? 

Thanks