[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[Kicer86 at gmail dot com]

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

Michał Walenciak <Kicer86 at gmail dot com> changed:

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

--- Comment #3 from Michał Walenciak <Kicer86 at gmail dot com> 2011-02-06 19:30:06 UTC ---
Another idea is to simplify virtual calls.
At the final link, probably most of the virtual calls could be converted into
regural calls (as whole program is known, and some base classes may have only
one (or zero) descendant, so all virtual calls will affect only it).

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |missed-optimization
           Priority|P3                          |P4

--- Comment #4 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2011-11-21 15:50:11 UTC ---
(In reply to comment #0)

> Class test
> {
>     virtual void example();
> };

Would you please post some real code that shows the problem and actually
*compiles* with, e.g.

avr-g++ -c vtable.cpp

instead of the lines above that trigger syntax error?

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[tfrancuz at mp dot pl]

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

--- Comment #5 from Tomasz Francuz <tfrancuz at mp dot pl> 2011-11-24 21:56:17 UTC ---
Ok, here is the code:
class test
{
 public:
  test() {};
  virtual void vfunction();
};

void test::vfunction()
{
}


int main()
{
}

After compilation 6 bytes of SRAM is occupied by test object vtable. Here is a
resulting part of map file:
*(.data)
 .data          0x00800100        0x0
c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr51/crtm128.o
 .data          0x00800100        0x6 gpp.o
                0x00800100                vtable for test
 .data          0x00800106        0x0
c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/avr51\libgcc.a(_exit.o)
 *(.data*)

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |addr-space
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-07
            Version|4.3.5                       |4.7.0
     Ever Confirmed|0                           |1

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[RiccardoManfrin at email dot it]

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

Riccardo Manfrin <RiccardoManfrin at email dot it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |RiccardoManfrin at email
                   |                            |dot it

--- Comment #6 from Riccardo Manfrin <RiccardoManfrin at email dot it> 2012-11-29 11:57:58 UTC ---
I'm also experiencing this issue and would like a patch or something to be able
to directly access vtables from flash on need.
I'd like to know if anyone has found even a temporary fix to that (even though
it means losing to a non portable solution/bad code ...).
R

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[d.come at isae dot fr]

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

Côme David <d.come at isae dot fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d.come at isae dot fr

--- Comment #7 from Côme David <d.come at isae dot fr> 2013-04-26 11:54:03 UTC ---
Hello.

I'm currently facing the exact same problem. I have a several classes with
virtual methods and 50% of my RAM is taken by the vtables of these classes.

I'm still willing to know if someone has come up with a solution/workaround for
this.

Thank you !
>From gcc-bugs-return-421020-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 26 11:57:14 2013
Return-Path: <gcc-bugs-return-421020-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10905 invoked by alias); 26 Apr 2013 11:57:14 -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 10879 invoked by uid 48); 26 Apr 2013 11:57:11 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57081] [4.9 Regression] Segmentation fault in simple_iv (tree-scalar-evolution.c:3151)
Date: Fri, 26 Apr 2013 11:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Changed-Fields: Status Last reconfirmed AssignedTo Target Milestone Summary Ever Confirmed
Message-ID: <bug-57081-4-eGtPJDG6fl@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57081-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57081-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
X-SW-Source: 2013-04/txt/msg02165.txt.bz2
Content-length: 1302


http://gcc.gnu.org/bugzilla/show_bug.cgi?idW081

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-04-26
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.9.0
            Summary|Segmentation fault in       |[4.9 Regression]
                   |simple_iv                   |Segmentation fault in
                   |(tree-scalar-evolution.c:31 |simple_iv
                   |51)                         |(tree-scalar-evolution.c:31
                   |                            |51)
     Ever Confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-04-26 11:57:10 UTC ---
(gdb) call debug_tree (op)
 <ssa_name 0x7ffff6d05ab0 nothrow var <var_decl 0x7ffff6d242f8 b>def_stmt

    version 1 in-free-list>
(gdb) call debug_gimple_stmt (stmt)
if (b_1 != 0)

It looks at loop->bounds which are appearantly not freed by the pass
creating them.

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |c++

--- Comment #8 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
This needs extensions in the C++ front => Component = c++

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #9 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug c++/43745] [avr] g++ puts VTABLES in SRAM

[timturnerc at yahoo dot com]

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

Tim Turner <timturnerc at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timturnerc at yahoo dot com

--- Comment #15 from Tim Turner <timturnerc at yahoo dot com> ---
Possibly similar to 23220 however on 64-bit recent Debian sid with
trivial code I see : https://www.webb-dev.co.uk/category/crypto/

mimas$ 
mimas$ uname -a  http://www.compilatori.com/category/services/
Linux mimas 5.10.0-6-sparc64 #1 Debian 5.10.28-1 (2021-04-09) sparc64 GNU/Linux
mimas$ 
http://www.acpirateradio.co.uk/category/services/
mimas$ 
mimas$ /usr/bin/gcc --version  http://www.logoarts.co.uk/category/services/
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
http://www.mconstantine.co.uk/crypto/kilimanjaro/
This is free software; see the source for copying conditions.  There is NO
http://www.slipstone.co.uk/category/services/ 
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

mimas$  http://embermanchester.uk/category/services/

mimas$ 
mimas$ cat -n foo.c  http://connstr.net/category/services/
     1
     2  #include <stdio.h>
     3  #include <stdlib.h>
     4 http://joerg.li/category/services/
     5  int main(int argc, char **argv)
     6  {
     7      int a = 1;
     8 http://www.jopspeech.com/category/services/
     9      printf("a = %i\n", a);
    10 http://www.wearelondonmade.com/category/services/
    11      printf("&a = %p\n", &a);
    12
    13      return EXIT_SUCCESS;
    14 https://waytowhatsnext.com/category/crypto/
    15  }
    16
mimas$  http://www.iu-bloomington.com/category/crypto/

mimas$ 
mimas$ /usr/bin/gcc -std=iso9899:1999 -pedantic -pedantic-errors -fno-builtin
https://komiya-dental.com/category/crypto/  -g -m64 -O0 -mno-app-regs
-mcpu=ultrasparc -mmemory-model=tso -o foo foo.c 
mimas$  http://www-look-4.com/category/services/

mimas$ 
mimas$ TERM=dumb LC_ALL=C /usr/bin/gdb ./foo https://www.mktrade.fi/ruiskuvalu
GNU gdb (Debian 10.1-2) 10.1.90.20210103-git g -m64 -O0 -mno-app-regs
-mcpu=ultrasparc -mmemory-model=tso -o
http://www.go-mk-websites.co.uk/crypto/namibia/ foo foo. g -m64 -O0
-mno-app-regs -mcpu=ultrasparc -mmemory-model=tso
http://fishingnewsletters.co.uk/services/camping-equipment/ -o foo foo. g -m64
-O0 -mno-app-regs -mcpu=ultrasparc -mmemory-model=tso -o foo foo.

[Bug c++/43745] New: g++ puts VTABLES in SRAM

[tfrancuz at mp dot pl]

On AVR target g++ generates code which copies object’s VTABLES from FLASH
to SRAM wasting the memory. Due to the Harvard architecture of AVR processors
the solution is not trivial. This behavior can be observed in any c++ program
which has object with virtual method, e.g:
Class test
{
        virtual void example();
};

The VTABLE of class test will be generated in FLASH and next copied to SRAM,
any reference to virtual example() method will take the method address from
SRAM.


-- 
           Summary: g++ puts VTABLES in SRAM
           Product: gcc
           Version: 4.3.5
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tfrancuz at mp dot pl


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

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[eric dot weddington at atmel dot com]

------- Comment #1 from eric dot weddington at atmel dot com  2010-04-14 19:52 -------
What is your suggestion?


-- 

eric dot weddington at atmel dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target
 GCC target triplet|                            |avr
            Summary|g++ puts VTABLES in SRAM    |[avr] g++ puts VTABLES in
                   |                            |SRAM


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

[Bug target/43745] [avr] g++ puts VTABLES in SRAM

[tfrancuz at mp dot pl]

------- Comment #2 from tfrancuz at mp dot pl  2010-04-14 20:39 -------
(In reply to comment #1)
> What is your suggestion?

Because VTABLES are generated during compile time and they are const data there
is no need to copy them into SRAM. Appropriate addresses of virtual methods can
be read directly from FLASH and used to make indirect call as usual. As far as
I know the problem is that AVR port of gcc doesn’t have appropriate isns
to do that. The problem is extremely important because for example my program
uses 964 bytes of SRAM, from which 860 bytes are used for VTABLES (wasted).
This is a typical situation for any C++ program on AVR.
The only problem is speed penalty, LD instruction on AVR takes 1 cycle, whereas
LPM instruction needed for FLASH access 3 cycles, which gives total 2 or 6
cycles to read virtual method address respectively. So probably the best
solution is to add another gcc option (or pragma) to choose between storing
VTABLES only in FLASH (slower code execution) or moving it to SRAM (faster
execution for the cost of higher SRAM memory occupation).


-- 

tfrancuz at mp dot pl changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tfrancuz at mp dot pl


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