[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]

------- 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?

[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?

[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] Why the C++ compiler don't place a const class object to ".rodata" section?

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-28 22:40 -------
Suspending as this will take a major change in the C++ front-end.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED
           Keywords|                            |pessimizes-code


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]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-20 18:44 -------
*** Bug 22575 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pluto at agmk dot net


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?

[pluto at agmk dot net]

------- Additional Comments From pluto at agmk dot net  2005-07-20 18:53 -------
hmm, i think someone should reopen this bug. 
4.1 is a good place for major changes in c++ front-end ;) 
 

-- 


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]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-07-20 18:58 -------
(In reply to comment #4)
> hmm, i think someone should reopen this bug. 
> 4.1 is a good place for major changes in c++ front-end ;) 
Not any more since we are in stage3 already.

-- 


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?

[schlie at comcast dot net]

------- Additional Comments From schlie at comcast dot net  2005-07-20 19:03 -------
(In reply to comment #5)
> (In reply to comment #4)
> > hmm, i think someone should reopen this bug. 
> > 4.1 is a good place for major changes in c++ front-end ;) 
> Not any more since we are in stage3 already.

- given that 4.1's front end has already evolved from that in 2.95,
   it's not clear that a conclusion based on 2.95 is even valid for 4.1.
   (so should no likely assumed as being so).


-- 


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

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

[Andrew Pinski]

On Jul 20, 2005, at 3:03 PM, schlie at comcast dot net wrote:

> - given that 4.1's front end has already evolved from that in 2.95,
>    it's not clear that a conclusion based on 2.95 is even valid for 
> 4.1.
>    (so should no likely assumed as being so).

It still is true since the front-end still does exactly what it did in 
2.95 for
this testcase and there have been no changes in this area really.

Since the mainline is in stage3 which means no more improvements except 
for fixing
bugs which are either regressions or non enhancement bugs.

-- Pinski

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

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-07-20 19:11 -------
Subject: Re:  Why the C++ compiler don't place a const class object to ".rodata" section?


On Jul 20, 2005, at 3:03 PM, schlie at comcast dot net wrote:

> - given that 4.1's front end has already evolved from that in 2.95,
>    it's not clear that a conclusion based on 2.95 is even valid for 
> 4.1.
>    (so should no likely assumed as being so).

It still is true since the front-end still does exactly what it did in 
2.95 for
this testcase and there have been no changes in this area really.

Since the mainline is in stage3 which means no more improvements except 
for fixing
bugs which are either regressions or non enhancement bugs.

-- Pinski



-- 


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?

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2005-07-20 19:47 -------
It may be true that this bug isn't going to be fixed in this cycle, 
but there's no reason not to keep it open instead of suspending it. 
The "suspend" state is mean for PRs where we need external things to 
happen, such as a defect report to be accepted. This clearly isn't the 
case here. 
 
I'll close this PR and reopen 22575 instead. 
 
W. 

*** This bug has been marked as a duplicate of 22575 ***

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


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