Hello!
There is very good blog post about the problem:
http://vladimir_prus.blogspot.com/2005/03/duplicate-function-bodies.html
A couple of days ago I've learned that the Microsoft linker can merge
functions with binary identical bodies. Looks rather good idea,
> especially with templates, and
Hi Kalaky,
#1. Please do not cross post to GCC-help and GCC lists.
#2. GCC@gcc.gnu.org is not an appropriate forum for your question.
#3. [EMAIL PROTECTED] is not an appropriate forum for your question.
#4. Your question is a general C++ question, not a GCC question.
> Given that removing/
Hi,
Isn't this what you describe here the same as COMDAT?
Gr.
Steven
On 9/15/06, Michael Popov <[EMAIL PROTECTED]> wrote:
Hello!
There is very good blog post about the problem:
http://vladimir_prus.blogspot.com/2005/03/duplicate-function-bodies.html
> A couple of days ago I've learned that
I have downloaded and built gcc-core and gcc-g++ (both
4.1.1).
I am not able to locate the yacc file for C++.
I want to experiment with some grammar changes.
-Suresh
__
Yahoo! India Answers: Share what you know. Learn
Steven Bosscher wrote:
Isn't this what you describe here the same as COMDAT?
Well, MS VC have an option "enable COMDAT folding" - which
turns ON merging of identical functions.
BTW, this is linker option... should it be addressed to GCC's LTO?
I'm not sure if function body is equivalent to "COM
Hi all,
i am trying to build a GCC Cross-compiler for Cold Fire on cygwin. The
Source versions i am using are
binutils 2.17
gcc 4.1.1
newlib 1.14
The way in which i am building the tool chain
- build/install binutils:
cd /binutil-2.17
./configure --target=m68k-elf --prefix=/usr
make
make i
Suresh Shukla wrote:
I have downloaded and built gcc-core and gcc-g++ (both
4.1.1).
I am not able to locate the yacc file for C++.
I want to experiment with some grammar changes.
All parsers in GCC, but the Java parser, are hand written. The C++
parser is in gcc/cp/parser.c and was rewritt
Geoff,
Are we now passing gcc.dg/20020103-1.c on Darwin due to
the newer cctools in Xcode 2.4? I ask because I'm going to
prepare patches tonight to eliminate some of the XPASS results
in the libstdc++ testsuite tonight and post them to gcc-patches.
If the newer Xcode is the origin of the new g
Hi,
I'm trying to test our Compiler (ported from gcc-3.4.2) using the gcc
test suite.
According to some reasons, I need to pass some options to arch-linux-elf-run in
the dejagnu frame work. Is there anyone can give me a hint about his?
Thanks in advance,
Aladdin
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> Isn't this what you describe here the same as COMDAT?
Not exactly. COMDAT means that the compiler can generate multiple
instances of, say, the list functions, and only one version will
be included in the final executable. However, if you use both
I must be doing something extraordinarily stupid, but I can't figure out
what it is: I can't bootstrap anymore since subversion revisions from
early January this year on a system as widely available as stock SuSE10.1.
Here's what's happening: starting with revision 109241
---
On 15 Sep 2006 09:27:32 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Steven Bosscher" <[EMAIL PROTECTED]> writes:
> Isn't this what you describe here the same as COMDAT?
Not exactly. COMDAT means that the compiler can generate multiple
instances of, say, the list functions, and only one
Rohit Arul Raj wrote:
Hi all,
i am trying to build a GCC Cross-compiler for Cold Fire on cygwin. The
Source versions i am using are
binutils 2.17
gcc 4.1.1
newlib 1.14
The way in which i am building the tool chain
- build/install binutils:
cd /binutil-2.17
./configure --target=m68k-elf --pr
On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote:
> I think Danny has a 75% implementation based on hashing the RTL for a
> section and using that to select the COMDAT section signature. Or the
> hashing can be done in the linker, but it still needs compiler help to
> know when it is perm
Daniel Berlin wrote:
There are of course, collisions possible in the hash, and in the
absolute worst case, it is possible to end up with no warning but
wrong results. In particular, if you get a collision and the length
of the functions happens to be the same, i don't believe the linker
will com
On 9/15/06, Michael Popov <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
> There are of course, collisions possible in the hash, and in the
> absolute worst case, it is possible to end up with no warning but
> wrong results. In particular, if you get a collision and the length
> of the function
On 9/15/06, Laurent GUERBY <[EMAIL PROTECTED]> wrote:
On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote:
> I think Danny has a 75% implementation based on hashing the RTL for a
> section and using that to select the COMDAT section signature. Or the
> hashing can be done in the linker, bu
On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote:
> >> I think Danny has a 75% implementation based on hashing the RTL for a
> >> section and using that to select the COMDAT section signature. Or the
> >> hashing can be done in the linker, but it still needs compiler help to
> >> know wh
Laurent GUERBY <[EMAIL PROTECTED]> writes:
> On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote:
> > I think Danny has a 75% implementation based on hashing the RTL for a
> > section and using that to select the COMDAT section signature. Or the
> > hashing can be done in the linker, but it
It seems to me that most candidates for merging that could be
eliminated by this approach are of the form
std::container::some_method(...)
Actually, even for non-POD types, it catches a lot of templatized
member functions that mainly depend on size (but they are still
container classes).
On 15 Sep 2006 13:54:00 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Laurent GUERBY <[EMAIL PROTECTED]> writes:
> On Fri, 2006-09-15 at 09:27 -0700, Ian Lance Taylor wrote:
> > I think Danny has a 75% implementation based on hashing the RTL for a
> > section and using that to select the CO
Ian Lance Taylor wrote:
>I think Danny has a 75% implementation based on hashing the RTL for a
>section and using that to select the COMDAT section signature.
I don't think this is a good idea. With different compiler options the
same RTL can generate different assembly instructions. Consider th
On Fri, 2006-09-15 at 13:54 -0700, Ian Lance Taylor wrote:
> Laurent GUERBY <[EMAIL PROTECTED]> writes:
> > For code sections (I assume read-only), isn't the linker always able to
> > merge identical ones? What can the compiler do better than the linker?
>
> The linker can't merge just any identi
Laurent GUERBY wrote:
On Fri, 2006-09-15 at 13:54 -0700, Ian Lance Taylor wrote:
Laurent GUERBY <[EMAIL PROTECTED]> writes:
For code sections (I assume read-only), isn't the linker always able to
merge identical ones? What can the compiler do better than the linker?
The linker can't merge just
Snapshot gcc-4.1-20060915 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060915/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
I'm trying to add a hook for aligning vectors for loads.
I'm using the altivec rs6000 code as a baseline.
However, the instruction is like the iwmmxt_walign instruction in the
ARM port; it takes
a normalish register and uses the bottom bits... it doesn't use a
full-width vector.
GCC complains w
I noticed that at least on Darwin PPC -m32 and -m64
we have been passing the test cases...
XPASS: 21_strings/basic_string/element_access/char/21674.cc execution test
XPASS: 21_strings/basic_string/element_access/wchar_t/21674.cc execution test
in the libstdc++ testsuite. From what I see in bug
On 9/15/06, Ross Ridge <[EMAIL PROTECTED]> wrote:
Ian Lance Taylor wrote:
>I think Danny has a 75% implementation based on hashing the RTL for a
>section and using that to select the COMDAT section signature.
I don't think this is a good idea. With different compiler options the
same RTL can ge
Ross Ridge writes:
>I don't think this is a good idea. With different compiler options the
>same RTL can generate different assembly instructions. Consider the case
>of compiling the same function multiple times with different names and
>different CPU architectures selected. You'd actually want
On 9/15/06, Ross Ridge <[EMAIL PROTECTED]> wrote:
Ross Ridge writes:
>I don't think this is a good idea. With different compiler options the
>same RTL can generate different assembly instructions. Consider the case
>of compiling the same function multiple times with different names and
>differ
30 matches
Mail list logo
