C++ Template instantiations efficiency (COMDAT, LINKONCE, ...) status in gcc 4.X series
Hi and thanks to the contributors of g++ (and the whole gcc suite) ... what a tremendous value! If I have to pinpoint my question, I would refer to gcc internals documentation section 11.10.4 "Functions for C++", macro name DECL_LINKONCE_P which is said to be "Not yet implemented". Then the question is "Can we expect further (compile-and-link time) efficiencies when this internal DECL_LINKONCE_P is implemented in a later release in the 4.X series? I assume the answer is no, as long as COMDAT support is provided in the linker. If such is the case, the suggestion is to add e.g. "The usefulness of DECL_LINKONCE_P appears questionable because COMDAT support by the link process is needed anyway for avoiding object code duplication and DECL_LINKONCE_P has no influence on this matter." Generally, the optimization of template instantiations remains a bit obscure for the g++ user. The performance improvement announced with gcc 4.5 seems unrelated to the COMDAT optimization of executable size. Is this correct? On one project, I used -fno-implicit-templates since I felt that a static library build process would benefit from it (every anticipated template specializations is included in the library). On another project, I felt a need to use -frepo (I don't recall exactly why). While trying to merge the two projects, I found that the g++ compiler (with GNU ld) was working just fine with the default setting for template specializations. Seems great! (Thinking while I write now, maybe DECL_LINKONCE_P might be relevant to distinguish compilation runs with -frepo in contexts where the link process does not support COMDAT.) If you follow my thinking (I'm not sure I always do when applying advanced C++ abstraction in actual code development), I wish to have an understanding of compile-time efficiencies when the C++ template mechanism is heavily used. More specifically, I am afraid that compile-time would become un-manageable as a project grows from a code base just too heavily dependent on the STL. But the STL concepts are so attractive! Once upon a time there was the Borland model ... I guess g++ makes this a thing of the past. Is this a fair assessment? Best regards. -- - Thierry Moreau CONNOTECH Experts-conseils inc.
Environment setting LDFLAGS ineffective after installation stage 1. Any workaround?
Dear compiler gurus, I wish to have executables with the library path (-Wl,-rpath=$HOME/tools/lib) embedded. This is intended to facilitate executables compiled with various versions/release candidates/snapshots run without keeping track of LD_LIBRARY_PATH. (modifying the specs file seems more intricate than setting environment variables for my purpose). With export LDFLAGS="-Wl,-rpath-link=$HOME/tools/lib -Wl,-rpath=$HOME/tools/lib" it works for binutils executables, and application executables created with a straightforward autoconf/automake build process. I can see that the -rpath was effective with objdump -x $HOME/tools/bin/my_as | grep tools which reports RPATH /home/tmoreau/tools/lib But with the gcc (latest 4.6.1 snapshot), -rpath (requested through LDFLAGS as indicated above) is effective only for executables built in stage 1 (and fixincl), but not for the installed gcc executables. Is it intentional that the LDFLAGS environment setting is partially effective during gcc build? Thank in advance. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691 P.S. Thinking while I write, maybe this has to do with the way recursive configure carry (or drop) environment settings (and the fact that gcc installation might use recursion mechanisms more creatively than e.g. binutils). (Thanks for providing an opportunity to write so I can think!)
Re: Environment setting LDFLAGS ineffective after installation stage 1. Any workaround?
Marc Glisse wrote: (gcc-help ?) On Tue, 31 May 2011, Thierry Moreau wrote: But with the gcc (latest 4.6.1 snapshot), -rpath (requested through LDFLAGS as indicated above) is effective only for executables built in stage 1 (and fixincl), but not for the installed gcc executables. Is it intentional that the LDFLAGS environment setting is partially effective during gcc build? Yes. For further stages, there is BOOT_LDFLAGS. There is also a configure option with a similar name. --with-stage1-ldflags= --with-boot-ldflags= see: http://gcc.gnu.org/install/configure.html Thanks, Indeed, -with-boot-ldflags="-Wl,-rpath-link=$HOME/tools/lib -Wl,-rpath=$HOME/tools/lib" did allow me to get gcc executables with embedded references to shared library directory. Less dependency on ldconfig and/or LD_LIBRARY_PATH, but more dependency on exact library files being accessible as long as the executables are present. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691
Re: Heapless C/C++, embedded systems requirements out of scope
Charles Wilson wrote: The reason many real-time systems disallow use of the heap is because it is well-known that heap management does not have a bounded-time implementation. Usually during free()/delete, typical heap management code often tries to coalesce freed blocks, or perform various other book-keeping. The length of time this takes is dependent on the usage pattern of the process. There are approaches to minimize the 'unboundedness' but that's like attempting to be "a little bit pregnant". In a properly designed embedded system, the finish-time-unpredictable portion of free()/delete/delete[] is deferred to a low priority runtime context, with a queue of requests. Then the heap is available to time-critical contexts. The system design must ensure that activity bursts are handled: the compiler can not assist this aspect. Otherwise, yes, there are embedded systems where a heap is absent. Anyway, such requirements appears out of scope for GCC development. Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691
Re: Is it possible to make gcc detect whether printf prints floating point numbers?
Joseph S. Myers wrote: On Tue, 12 Jun 2012, Bin.Cheng wrote: I noticed that GCC now can check format string of printf functions, so I am wondering if it is possible to take advantage of this utility, by making gcc detect whether printf prints floating point number and then generate assembly directive in backend to pull in floating point functions only if necessary. Obviously this won't help if the program is using functions such as vprintf to print things with variable format strings One method is to analyze the type of arguments when format strings are varying. Though this method might fail when user trying to output a "long long" type int with conversion specifier "%f", I think it's not a big deal. That method won't help for vprintf (unless you do something more complicated and interprocedural) since then you have just a (probably nonconstant) format strict and a (definitely nonconstant) va_list so don't know the types of the arguments at all. The original question does not belong to gcc development. It's an embedded software tools issue. The straightforward solution is to supply the (library internal) ...printf() function that ultimately handles any C-style output format string. I mean a variant of this function that does not support floating point output. I used the word straightforward because embedded software development usually implies more intricate issues with the run-time support library (exception handling, dynamic memory, linker issues). The more serious the memory restrictions in the embedded environment, the more critical these issues become. Let gcc development proceed as a great compiler technology! Regards, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, QC, Canada H2M 2A1 Tel. +1-514-385-5691
C++ conversion: an observation about minimum compiler version
Hi,
This is just an observation, but maybe there is a potential problem.
I am a happy user of GCC and I have many 4.x versions that I use on
three development Linux boxes. The C++ template code in annex triggers a
compile-time error on 4.2, 4.4, 4.6, but not on 4.7. (I suppose this bug
has been found and tracked before.)
No problem with me, I have done projects with significantly less
reliable development tools in the past. I will either upgrade or use a
work-around in the source code (I chose to upgrade, this is server-side
code where tools are under the project leader control).
The observation is *if* the gcc source code has some C++ depency(ies)
which similarly needs say version>=4.7 and a machine has only gcc 4.4
installed, then migrating to e.g. gcc 5.3 requires installing v.X, (4.7
<= X < first-version-that-can't-be-compiled-without-C++).
My observation further hints that that "X" should be decided, and then
lasting support for version "X" should be planned (I say "should" but
who am I to request anything?)
The potential problem, from a tools user perspective, is that upgrading
from 4.4 to 5.3 might be frustrating because the tools user would not
have been warned about planning for an intermediate version
installation. The potential problem is thus one of migration help file,
no less and no more.
Again, many thanks for these development tools.
Regards
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
===
template class t1
{
public:
int length;
};
template class t2 : public t1
{
public:
void f();
};
template
void t2::f()
{
int &len=(t1::length); // ok
t1::length=100; // ok
unsigned char *val=new unsigned char[t1::length]; // ok
int ln=-(t1::length); // ok
int *ptlen=&(t1::length); // address-of operator in this
// base class template member access
// ==> compiler bug with gcc 4.2 to 4.6
}
void fstatic()
{
t2<1000> obj;
obj.f(); // instantiate ...
}
===
In member function 'void t2::f() [with int SIZE = 1000]':
error: cannot convert 'int t1<1000>::*' to 'int*' in initialization
===
Re: C++ conversion: an observation about minimum compiler version
This is now bugzilla 56558.
Thierry Moreau wrote:
Hi,
The C++ template code in annex triggers a
compile-time error on 4.2, 4.4, 4.6, but not on 4.7. (I suppose this bug
has been found and tracked before.)
===
template class t1
{
public:
int length;
};
template class t2 : public t1
{
public:
void f();
};
template
void t2::f()
{
int &len=(t1::length); // ok
t1::length=100; // ok
unsigned char *val=new unsigned char[t1::length]; // ok
int ln=-(t1::length); // ok
int *ptlen=&(t1::length); // address-of operator in this
// base class template member access
// ==> compiler bug with gcc 4.2 to 4.6
}
void fstatic()
{
t2<1000> obj;
obj.f(); // instantiate ...
}
===
In member function 'void t2::f() [with int SIZE = 1000]':
error: cannot convert 'int t1<1000>::*' to 'int*' in initialization
===
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
