[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?

[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2005-11-18 00:51 -------
Reopening this bug since it is the correct one to keep open.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |


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

[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW


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

[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2005-11-18 00:55 -------
*** Bug 22575 has been marked as a duplicate of this bug. ***


-- 


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

[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?

[bjoern dot haase at de dot bosch dot com]

------- Comment #11 from bjoern dot haase at de dot bosch dot com  2006-08-10 12:11 -------
Hi,

here is a much simpler test case for this issue.

Bjoern.



#include <complex>

using namespace std;

const complex<char> should_be_in_rodata (42,-42);
complex<char> should_be_in_data (42,-42);
complex<char> should_be_in_bss;


-- 

bjoern dot haase at de dot bosch dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bjoern dot haase at de dot
                   |                            |bosch dot com


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

[Bug c++/4131] Why the C++ compiler don't place a const class object to ".rodata" section?

[mrs at apple dot com]

------- Comment #12 from mrs at apple dot com  2006-08-10 16:54 -------
Trivially, one could use turing completeness at compile time to achieve the
desired result.  :-)  Not that I think that is better than `fixing' this bug.


-- 


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trival constructor

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-08-10 17:52 -------
Here is a real reduced testcase:

struct f
{
  f(int a) { t = a; }
  int t;
}

const f(1);

-----


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Why the C++ compiler don't  |The C++ compiler don't place
                   |place a const class object  |a const class object to
                   |to ".rodata" section?       |".rodata" section with non
                   |                            |trival constructor


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trival constructor

[bjoern dot m dot haase at web dot de]

------- Comment #14 from bjoern dot m dot haase at web dot de  2006-08-10 19:33 -------
I had already a look at the code in the cp directory. Unfortunately the
documentation of the c++ front-end seems to be still worse than the docs on the
back-ends (i.e. RTL). Either it is virtually inexisting or, I didn't find any
hint on where to find it.

Meanwhile I had a look at the tree dumps. Unfortunately, I didn't succeed in
finding the initialization data for global "plain old built-in type" variables
in the tree dumps. I have so far only seen the constructor code for
initialization of class objects.


AI'd at least like to have an idea of the complexity of the task. I have the
impression that it might be way to difficult for me myself. But at least I'd
like to try my very best to fix it before giving up. 

So any hint on a starting point for code reading and analysis would be
appreciated.

Bjoern.


-- 


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trival constructor

[bjoern dot haase at de dot bosch dot com]

------- Comment #15 from bjoern dot haase at de dot bosch dot com  2006-08-11 07:48 -------
I just realized that yesterday the subject line has been changed.

I'd like to suggest that this new subject line is mis-leading:

The compiler doesn't place ANY object in .rodata . It's not necessary to have
a "non-trivial" constructor.
E.g. have a look at the constructors of the complex class template. There isn't
any statement in the constructor. There is only the initialization of the
member POD for the real and imaginary parts.

If one changes the subject line, I think that 

"the compiler don't place any const class object to .rodata"

would be appropriate.

Bjoern.


-- 


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[pinskia at gcc dot gnu dot org]

------- Comment #16 from pinskia at gcc dot gnu dot org  2006-08-11 08:04 -------
Non trivial is the wording used by the C++ standard which is why I used it. 
(it is also called user defined constructor).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|The C++ compiler don't place|The C++ compiler don't place
                   |a const class object to     |a const class object to
                   |".rodata" section with non  |".rodata" section with non
                   |trival constructor          |trivial constructor


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[bjoern dot m dot haase at web dot de]

------- Comment #17 from bjoern dot m dot haase at web dot de  2006-08-17 14:36 -------
I have made a superficial analysis of the issue and would like to discuss at
the end of this post a possible approach for resolving PR4131.

The first observation is, that when one is having a code segment like

/* Start */
#include <complex>
using namespace std;
typedef complex<int> ci;

ci fa [3] = {ci(1,2), ci(-1,-2), ci(-42,+42)};
/* End */

the gimple optimizers will yield a very simple code sequence like

/* Start of gimple code */
void __static_initialization_and_destruction_0(int, int) (__initialize_p,
__priority)
{
<bb 2>:
  if (__initialize_p == 1) goto <L0>; else goto <L2>;

<L0>:;
  if (__priority == 65535) goto <L1>; else goto <L2>;

<L1>:;
  fa[0]._M_real = 1;
  fa[0]._M_imag = 2;
  fa[1]._M_real = -1;
  fa[1]._M_imag = -2;
  fa[2]._M_real = -42;
  fa[2]._M_imag = 42;

<L2>:;
  return;
}
/* End of gimple code */

for the constructor function. Namely, I think that there is hope that one would
grep the most important cases if one would try to replace
 some_direct_address_in_data_member = const_immediate_integer;
expressions in the constructors by storing the value in the .data initializers.
Namely, one would be placing the values in the initialization memory region and
one would be deleting the assignment expressions.
If at the end of this process, the constructor function would no longer contain
references to the data structure, "const" qualified VAR_DECL could even be
placed in ".rodata".

Thus, for fixing PR4131 I'd like to suggest to

1.) change the definition of the VAR_DECL so that DECL_INITIAL always points
    to a memory region holding initialization data. I.e. also for the case
    that we are having constructor code. Initially the memory region would
    be initialized to 0.
2.) In order to do this, one would need to replace the tests
    "DECL_INITIAL(decl) == error_mark_node" by tests against one of the unused
    flags in tree_decl_common that would be assigned a new meaning.
    E.g., one might take "decl_flag_0" which seems to be unused so far
    for VAR_DECL.? 
3.) One would then add a new tree optimiation pass that is located somewhere
    close to the end of tree optimization. There one would be looking for
    expressions like "static_direct_address = const_immediate_value" like
    in the sample gimple code above.
    One wold be inserting the values in the DECL_INITIAL(decl) memory region
    delete the corresponding expression statements in the constructor function.
    After making all the possible replacements, one would be re-visiting the 
    code of the constructor function.
    If within the constructor code more complex references to the VAR_DECL
    remain, that could not be removed easily, one would set one second flag
    in "tree_decl_common" that states that the VAR_DECL needs to reside in ram,
    even if it's a const object.
4.) In "var_asm.c" one would be checking if DECL_INITIAL(decl) is completely
    zero. In this case it would go into .bss. If the initialization memory
    region is not zero altogether, one would place the object in .data .
    If it's a const object without the flag
    "needs_to_reside_in_ram_even_if_const" it would be placed into .rodata.


IMO, the most complicated part of it would be the new tree pass 3.).

Namely, one would need to find the approriate branch in

void __static_initialization_and_destruction_0(int, int) (__initialize_p,
__priority);

, look for "direct_address_expression = immediate_integer_value;" type
expression statements that are not residing inside loops or other complicated
structures and delete them if possible.
Then one would be looking if there is any reference to some VAR_DECL remaining
in the FUNCTION_DECL of the constructor function. If there is still a
reference,
one would be setting the "needs_to_reside_in_ram_even_if_const" flag.
Otherwise one would clear it.

I would be willing to start with implementing 1,2 and 4, but I am quite sure 
that I would need help for 3.

Bjoern.


-- 


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[pinskia at gcc dot gnu dot org]

------- Comment #18 from pinskia at gcc dot gnu dot org  2006-11-29 23:22 -------
*** Bug 30023 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zackw at panix dot com


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[pinskia at gcc dot gnu dot org]

------- Comment #19 from pinskia at gcc dot gnu dot org  2007-05-02 14:55 -------
*** Bug 31785 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[jorg dot brown at gmail dot com]

------- Comment #20 from jorg dot brown at gmail dot com  2008-06-11 00:07 -------
Interesting, but I'm not sure this can legally be done.

Consider:

struct POD {
  int x;
  int y;
};

struct nonPOD {
  int x;
  int y;
  nonPOD(int xx, int yy) : x(xx), y(yy) { }
};

I, for one, would love to see "nonPOD foo(1, 2);" be treated as efficiently as
"POD foo = {1, 2};", and I would argue that the case that should be optimized
is when the arguments to the constructor are known at compile time, the body of
the constructor is completely empty, and all the member variables are POD.

However let us consider this example program, starting with the definitions
above and the requisite header files and then:

extern const POD    pod;
extern const nonPOD nonpod;

std::string podStr(pod.x, '*');
std::string nonpodStr(nonpod.x, '*');

const POD pod = {1, 2};
const nonPOD nonpod(1, 2);

int main(int argc, char *argv[]) {
  std::cout << "podStr = '" << podStr << "'\n";
  std::cout << "nonpodStr = '" << nonpodStr << "'\n";
  return 0;
}

Now, the order of construction is well-defined, and that is why the program
produces:

podStr = '*'
nonpodStr = ''

That is, the nonPOD is still zero-filled when the constructor for nonpodStr
runs, so nonpodStr ends up empty.

I believe that if you change nonPOD so that it sits in .rodata, then it has to
be initialized prior to nonpodStr.  This changes the behavior of this perfectly
valid program.  No?

(Just for the record, I would whole-heartedly endorse a change to the C++
standard to allow this optimization)


-- 


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2008-06-11 02:17 -------
Well if done correctly the compiler would see that nonpod.x was used for the
initialization and inline it as zero :).  So really this can be still done.


-- 


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[jyasskin at gmail dot com]

------- Comment #22 from jyasskin at gmail dot com  2008-06-11 18:05 -------
This is related to generalized constant expressions
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2235.pdf) in C++0x.
Those will be marked by the explicit 'constexpr' keyword and will require the
initialization to be done at static rather than dynamic initialization time,
while this bug is about the optional optimization of moving some extra objects
from dynamic to static time.

If I understand it correctly, in C++0x, the following code will require f to be
placed in either the .rodata or .data sections, rather than .bss as it's placed
now.

struct Foo
{
  constexpr Foo(int a) { t = a; }
  int t;
}

constexpr Foo f(1);


I'd also like to point out that with the extra optimization described here, the
following code could also place f in the .data section:

struct Foo
{
  constexpr Foo(int a) { t = a; }
  int t;
}

Foo f(1);  // Note that f is non-const.

This would be useful for getting atomic variables initialized before anything
else starts up, but it may well belong in a separate feature request.


-- 

jyasskin at gmail dot com changed:

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


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[pinskia at gcc dot gnu dot org]

------- Comment #23 from pinskia at gcc dot gnu dot org  2010-06-27 22:09 -------
*** Bug 44638 has been marked as a duplicate of this bug. ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tglek at mozilla dot com


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[jakub at gcc dot gnu dot org]

------- Comment #24 from jakub at gcc dot gnu dot org  2010-06-28 11:05 -------
On:
extern "C" void abort ();

struct S
{
  int x;
  int y;
};

struct T
{
  int x;
  int y;
  T (int u, int v) : x (u), y (v) {}
};

extern const S s;
extern const T t, u;

int sx = s.x;
int tx = t.x;
const S s = { 1, 2 };
const T t (1, 2);
const T u (1, 2);
int ux = u.x;

int
main ()
{
  if (sx != 1 || tx != 0 || ux != 1)
    abort ();
  if (s.x != 1 || s.y != 2)
    abort ();
  if (t.x != 1 || t.y != 2)
    abort ();
  if (u.x != 1 || u.y != 2)
    abort ();
  return 0;
}

it is easy to spot whether this optimization would be possible or not by
looking at TREE_USED of the decl at check_initializer time.  It is set for t
(and s), but cleared for u.


-- 


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2010-06-28 11:22 -------
I guess best would be to wait for the constexpr work, then use that as an
infrastructure to discover ctors that aren't marked as constexpr, but they
could be and use that at bit together with !TREE_USED during check_initializer
to do this optimization.


-- 

jakub at gcc dot gnu dot org changed:

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


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

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mh+gcc at glandium dot org

--- Comment #27 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-07-02 07:12:27 UTC ---
*** Bug 53829 has been marked as a duplicate of this bug. ***

[Bug c++/4131] The C++ compiler don't place a const class object to ".rodata" section with non trivial constructor

[thiago at kde dot org]

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

Thiago Macieira <thiago at kde dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiago at kde dot org

--- Comment #26 from Thiago Macieira <thiago at kde dot org> 2011-07-08 08:03:50 UTC ---
Using GCC 4.6, which does support constexpr in C++0x mode, it turns out that
the compiler does place initialised variables in the .data section. However,
const variables are still in .data, not in .rodata.

I don't think they are the same issues, so I reported Bug 49673.