a problem when building gcc3.2.1
hi, I configure GCC as follow: PATH=/gnutools/bin:$PATH ; export PATH mkdir -p /tmp/build/gcc cd /tmp/build/gcc /src/gcc-3.2.1/configure --target=mipsel-elf \ --prefix=/gnutools --enable-languages=c,c++ \ --with-gnu-as --with-gnu-ld --with-newlib \ --without-headers --disable-shared --disable-threads Build and install GCC make then it shows the error: /src/gcc-3.2.1/libiberty/regex.c: At top level: /src/gcc-3.2.1/libiberty/regex.c:7959: error: storage size of `re_comp_buf' isn't known make[1]: *** [regex.o] Error 1 make[1]: Leaving directory `/tmp/build/gcc/mipsel-elf/libiberty' make: *** [all-target-libiberty] Error 2 make: Leaving directory `/tmp/build/gcc' what should i do?How to solve it?Thank you very much.
CIL back-end
Hello, I'm working for an R&D organization of STMicroelectronics. Within our team we have decided to write a gcc back-end that produces CIL binaries (compliant with ECMA specification, see http://www.ecma-international.org/publications/standards/Ecma-335.htm). Our main motivation is the ability to produce highly-optimized CIL binaries out of plain C code (and C++ in the future), and possibly to add some optimizations to improve, if needed, the quality of the generated code. There are other open source projects that come with a C to CIL compiler, but none is comparable with gcc in terms of program optimizations. In CIL, the semantic of a program is expressed in the form of a bytecode executable by a stack-based virtual machine (similarly with how Java works). As a new port, CIL substantially differs from the "typical" gcc target. For instance, RTL representation seems inappropriate since the virtual machine lacks registers, stack frames, ecc. and since RTL itself lacks high-level information (classes, methods, fields, exceptions...) required by CIL. In other words, compiling for CIL demands a more high-level intermediate representation, which gimple looks to match quite closely. Therefore, we think that the best way to target CIL is to cut gcc compilation flow at gimple level and to provide the simplest machine description that doesn't break gcc and that meaningfully drives the heuristics of the tree passes. Every so often CIL looks to poke in the works of the mailing list, but I haven't been able to track the current status of the discussion on the topic. What do you think about such a port? Are there any people interested? Of course, opinions, suggestions or any sort of feedback are highly appreciated. We would be glad to share our development. Cheers, Roberto
Re: Where is the egg?
> These are pngcrushed versions with linear dimensions between 50% and 80% of > the 200-pixel-high original. how about using a svg image as a master instead of a png? It could be scaled without loss. I attached a svg produced from the original png. Thomas gcc.svg.bz2 Description: Binary data
Re: a problem when building gcc3.2.1
Eric Fisher wrote: /src/gcc-3.2.1/configure --target=mipsel-elf \ --prefix=/gnutools --enable-languages=c,c++ \ --with-gnu-as --with-gnu-ld --with-newlib \ --without-headers --disable-shared --disable-threads Build and install GCC make Wrong command, use 'make all-gcc ; make install-gcc', then configure, build and install newlib, then continue with 'make'! then it shows the error: /src/gcc-3.2.1/libiberty/regex.c: At top level: /src/gcc-3.2.1/libiberty/regex.c:7959: error: storage size of `re_comp_buf' isn't known make[1]: *** [regex.o] Error 1 make[1]: Leaving directory `/tmp/build/gcc/mipsel-elf/libiberty' Can you guess whether producing newlib needs the newlib headers? Producing 'libiberty' and 'libstdc++' to be in sync with the newlib? Your choice is either having the newlib headers available or then trying to avoid them via the '--without-headers', but then you will get "only GCC" :-(
Re: Generator programs can only be built with optimization enabled?
David Edelsohn wrote: Mark Mitchell writes: Mark> That seems unfortunate, but so be it. Yes it is very unfortunate and not very convenient for the way that most developers want to use the build infrastructure. There no longer is an equivalent to "make quickstrap". To rebuild only GCC, one can use "make all-stageN-gcc" at the top-level. Andrew pointed out PR18058, where you can read: - Comment #33 From Andrew Pinski 2006-06-11 13:10 [reply] --- ... This was caused by: 2006-01-22 Zack Weinberg <[EMAIL PROTECTED]> * genautomata.c: Include vec.h, not varray.h. The problem that Mark reported happens because (since always) the CFLAGS of the gcc directory are just "-g", not "-O2 -g". Optimized builds have (since always) been done only because the toplevel overrides the "-g" CFLAGS. So, when you type "make" in the gcc directory, it triggers a non-optimized build of everything (generator programs, compiler, driver), which in turn triggers PR18058. So, let's please not confuse issues. I work in the GCC directory daily. I type "make" there and it just works. You can even type "make quickstrap" if you want: ifeq ($(BOOTSTRAPPING),yes) # Provide quickstrap as a target that people can type into the gcc # directory, and that fails if you're not into it. quickstrap: all else ... endif I think this was your suggestion, and it was implemented. If there are requests for improvements to the build infrastructure, please tell me clearly about them. However, I don't see how this is related to the problem that Mark reported. Paolo
help interpreting gcc 4.1.1 optimisation bug
I want a reduced test case for this problem for bugzilla, but don't
really know the exact cause. I _think_ code is being improperly
optimized away, but I don't know. This function is part of a
BigInteger library, and works perfectly upto and including -O2, but
produces bogus results at -O3, unless I uncomment the debug_msg()
line, which just dumps the contents of 'i' to the screen. I'm
guessing that without it, the compiler fails to notice that i's
contents are being accessed via the _front8/_back8 pointers, and
throws the preceeding 'i' related code away. Heres the code:
void Integer::export_bytes(Data& _buffer, PortMode _mode) const
{
debug_scope("export_bytes(Data&)");
Integer i(*this,1);
if (_mode==SIGNED) {
if (*mBack & TOP_BIT)
i.grow(1,0);
if (sign()<0)
i.twoscomplement();
}
for (UnsignedW* p=i.mFront; p<=i.mBack; p++)
*p = host2little(*p);
Unsigned8* _front8 = reinterpret_cast(i.mFront);
Unsigned8* _back8 = _front8+(i.mSize*WORD_BYTES)-1;
if (_mode==UNSIGNED)
while (_back8!=_front8 and *_back8==0)
_back8--;
else if (mSign==1)
while (_back8!=_front8 and *_back8==0 and
!(*(_back8-1)&0x80))
_back8--;
else
while (_back8!=_front8 and *_back8==0xff and
*(_back8-1)&0x80)
_back8--;
//debug_msg(String("Force i\n")+i.dump());
_buffer.assign(_front8, _back8+1);
}
Any thoughts on how to proceed?
Andrew Walrond
Re: help interpreting gcc 4.1.1 optimisation bug
[EMAIL PROTECTED] writes:
> I want a reduced test case for this problem for bugzilla, but don't
> really know the exact cause. I _think_ code is being improperly
> optimized away, but I don't know. This function is part of a
> BigInteger library, and works perfectly upto and including -O2, but
> produces bogus results at -O3, unless I uncomment the debug_msg()
> line, which just dumps the contents of 'i' to the screen. I'm
> guessing that without it, the compiler fails to notice that i's
> contents are being accessed via the _front8/_back8 pointers, and
> throws the preceeding 'i' related code away. Heres the code:
>
> void Integer::export_bytes(Data& _buffer, PortMode _mode) const
> {
> debug_scope("export_bytes(Data&)");
>
> Integer i(*this,1);
>
> if (_mode==SIGNED) {
> if (*mBack & TOP_BIT)
> i.grow(1,0);
> if (sign()<0)
> i.twoscomplement();
> }
>
> for (UnsignedW* p=i.mFront; p<=i.mBack; p++)
> *p = host2little(*p);
>
> Unsigned8* _front8 = reinterpret_cast(i.mFront);
> Unsigned8* _back8 = _front8+(i.mSize*WORD_BYTES)-1;
> if (_mode==UNSIGNED)
> while (_back8!=_front8 and *_back8==0)
> _back8--;
> else if (mSign==1)
> while (_back8!=_front8 and *_back8==0 and
>!(*(_back8-1)&0x80))
> _back8--;
> else
> while (_back8!=_front8 and *_back8==0xff and
>*(_back8-1)&0x80)
> _back8--;
>
> //debug_msg(String("Force i\n")+i.dump());
>
> _buffer.assign(_front8, _back8+1);
> }
>
> Any thoughts on how to proceed?
I think your code is broken. A reinterpret_cast from foo* to bar* is
only well-defined if foo and bar are compatible types or one of
{foo,bar} is type char. I can't be sure from your code, but I'm
guessing that i.mFront is not declared as a pointer to Unsigned8, but
as a pointer to an incompatible type UnsignedW.
Andrew.
Re: help interpreting gcc 4.1.1 optimisation bug
On Mon, Jun 12, 2006 at 12:32:36PM +0100, Andrew Haley wrote:
> [EMAIL PROTECTED] writes:
> > I want a reduced test case for this problem for bugzilla, but don't
> > really know the exact cause. I _think_ code is being improperly
> > optimized away, but I don't know. This function is part of a
> > BigInteger library, and works perfectly upto and including -O2, but
> > produces bogus results at -O3, unless I uncomment the debug_msg()
> > line, which just dumps the contents of 'i' to the screen. I'm
> > guessing that without it, the compiler fails to notice that i's
> > contents are being accessed via the _front8/_back8 pointers, and
> > throws the preceeding 'i' related code away. Heres the code:
> >
> > void Integer::export_bytes(Data& _buffer, PortMode _mode) const
> > {
> > debug_scope("export_bytes(Data&)");
> >
> > Integer i(*this,1);
> >
> > if (_mode==SIGNED) {
> > if (*mBack & TOP_BIT)
> > i.grow(1,0);
> > if (sign()<0)
> > i.twoscomplement();
> > }
> >
> > for (UnsignedW* p=i.mFront; p<=i.mBack; p++)
> > *p = host2little(*p);
> >
> > Unsigned8* _front8 = reinterpret_cast(i.mFront);
> > Unsigned8* _back8 = _front8+(i.mSize*WORD_BYTES)-1;
> > if (_mode==UNSIGNED)
> > while (_back8!=_front8 and *_back8==0)
> > _back8--;
> > else if (mSign==1)
> > while (_back8!=_front8 and *_back8==0 and
> >!(*(_back8-1)&0x80))
> > _back8--;
> > else
> > while (_back8!=_front8 and *_back8==0xff and
> >*(_back8-1)&0x80)
> > _back8--;
> >
> > //debug_msg(String("Force i\n")+i.dump());
> >
> > _buffer.assign(_front8, _back8+1);
> > }
> >
> > Any thoughts on how to proceed?
>
> I think your code is broken. A reinterpret_cast from foo* to bar* is
> only well-defined if foo and bar are compatible types or one of
> {foo,bar} is type char. I can't be sure from your code, but I'm
> guessing that i.mFront is not declared as a pointer to Unsigned8, but
> as a pointer to an incompatible type UnsignedW.
>
typedef unsigned long UnsignedW;
typedef unsigned char Unsigned8;
typdef std::vector Data;
mFront is defined as UnsignedW*, an array of words constituting the
big integer. Having converted the words from host to little endian
with host2little(), I am simply reading (exporting) the bytes out into
a vector using std::vector::assign(InputIter first, InputIter last)
Seems legit, no?
> Andrew.
>
Re: help interpreting gcc 4.1.1 optimisation bug
[EMAIL PROTECTED] writes:
> On Mon, Jun 12, 2006 at 12:32:36PM +0100, Andrew Haley wrote:
> > [EMAIL PROTECTED] writes:
> > > I want a reduced test case for this problem for bugzilla, but don't
> > > really know the exact cause. I _think_ code is being improperly
> > > optimized away, but I don't know. This function is part of a
> > > BigInteger library, and works perfectly upto and including -O2, but
> > > produces bogus results at -O3, unless I uncomment the debug_msg()
> > > line, which just dumps the contents of 'i' to the screen. I'm
> > > guessing that without it, the compiler fails to notice that i's
> > > contents are being accessed via the _front8/_back8 pointers, and
> > > throws the preceeding 'i' related code away. Heres the code:
> > >
> > > void Integer::export_bytes(Data& _buffer, PortMode _mode) const
> > > {
> > > debug_scope("export_bytes(Data&)");
> > >
> > > Integer i(*this,1);
> > >
> > > if (_mode==SIGNED) {
> > > if (*mBack & TOP_BIT)
> > > i.grow(1,0);
> > > if (sign()<0)
> > > i.twoscomplement();
> > > }
> > >
> > > for (UnsignedW* p=i.mFront; p<=i.mBack; p++)
> > > *p = host2little(*p);
> > >
> > > Unsigned8* _front8 = reinterpret_cast(i.mFront);
> > > Unsigned8* _back8 = _front8+(i.mSize*WORD_BYTES)-1;
> > > if (_mode==UNSIGNED)
> > > while (_back8!=_front8 and *_back8==0)
> > > _back8--;
> > > else if (mSign==1)
> > > while (_back8!=_front8 and *_back8==0 and
> > >!(*(_back8-1)&0x80))
> > > _back8--;
> > > else
> > > while (_back8!=_front8 and *_back8==0xff and
> > >*(_back8-1)&0x80)
> > > _back8--;
> > >
> > > //debug_msg(String("Force i\n")+i.dump());
> > >
> > > _buffer.assign(_front8, _back8+1);
> > > }
> > >
> > > Any thoughts on how to proceed?
> >
> > I think your code is broken. A reinterpret_cast from foo* to bar* is
> > only well-defined if foo and bar are compatible types or one of
> > {foo,bar} is type char. I can't be sure from your code, but I'm
> > guessing that i.mFront is not declared as a pointer to Unsigned8, but
> > as a pointer to an incompatible type UnsignedW.
>
> typedef unsigned long UnsignedW;
> typedef unsigned char Unsigned8;
> typdef std::vector Data;
>
> mFront is defined as UnsignedW*, an array of words constituting the
> big integer.
OK. That should be fine, then.
> Having converted the words from host to little endian with
> host2little(), I am simply reading (exporting) the bytes out into a
> vector using std::vector::assign(InputIter first, InputIter last)
>
> Seems legit, no?
The only likely significant difference with -O3 is that small
functions get inlined.
I'm starting to be a little suspicious about host2little(). I wonder
if that's well-defined.
I'm just guessing here becasue I can't see the code. Is it possible
for you to turn this into a small test case that anyone can run?
Andrew.
Re: help interpreting gcc 4.1.1 optimisation bug
On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
>
> I'm starting to be a little suspicious about host2little(). I wonder
> if that's well-defined.
>
> I'm just guessing here becasue I can't see the code. Is it possible
template T swap_endian(T x)
{
char* a = reinterpret_cast(&x);
char* b = a + sizeof(T) - 1;
while (a T host2little(T x)
{
unsigned u = 1; return (*reinterpret_cast(&u) ? x :
swap_endian(x));
}
> for you to turn this into a small test case that anyone can run?
Thats the plan. Once I have a clue whats going on, I'll be able to
generate a small testcase for bugzilla. I'm looking for some informed
guesses as to what might be happening in order to target my investigation...
>
> Andrew.
Re: CIL back-end
Roberto COSTA wrote on 06/12/06 03:50: > Every so often CIL looks to poke in the works of the mailing list, but I > haven't been able to track the current status of the discussion on the > topic. > We have started work on a bytecode representation that will initially be used for link-time optimizations (search the archives for LTO). The Wiki has a brief description of the cleanup work needed for it (http://gcc.gnu.org/wiki/LinkTimeCleanups).
Re: help interpreting gcc 4.1.1 optimisation bug
On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
>
> I'm starting to be a little suspicious about host2little(). I wonder
> if that's well-defined.
>
> I'm just guessing here becasue I can't see the code. Is it possible
template T swap_endian(T x)
{
char* a = reinterpret_cast(&x);
char* b = a + sizeof(T) - 1;
while (a T host2little(T x)
{
unsigned u = 1; return (*reinterpret_cast(&u) ? x :
swap_endian(x));
}
You are violating aliasing rules. Try -fno-strict-aliasing, which
should make the code
work, or fix it.
Richard.
Re: help interpreting gcc 4.1.1 optimisation bug
[EMAIL PROTECTED] writes:
> On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> >
> > I'm starting to be a little suspicious about host2little(). I wonder
> > if that's well-defined.
> >
> > I'm just guessing here becasue I can't see the code. Is it possible
>
> template T swap_endian(T x)
> {
> char* a = reinterpret_cast(&x);
> char* b = a + sizeof(T) - 1;
> while (a char tmp = *a;
> *a++ = *b;
> *b-- = tmp;
> }
> return x;
> }
Looks fine. All access is via char* or T.
> template T host2little(T x)
> {
> unsigned u = 1; return (*reinterpret_cast(&u) ? x :
> swap_endian(x));
> }
A little weird, but OK. :-)
> > for you to turn this into a small test case that anyone can run?
>
> Thats the plan. Once I have a clue whats going on, I'll be able to
> generate a small testcase for bugzilla. I'm looking for some
> informed guesses as to what might be happening in order to target
> my investigation...
Well, my informed guess is that Something Bad is happening with
pointer accesses. :-) So far I haven't seen anything definitely
wrong, but an example source file that simply takes the code you have
at the moment and includes the missing definitions so that anyone can
compile it would be a start.
Andrew.
Re: help interpreting gcc 4.1.1 optimisation bug
Richard Guenther writes:
> On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> > >
> > > I'm starting to be a little suspicious about host2little(). I wonder
> > > if that's well-defined.
> > >
> > > I'm just guessing here becasue I can't see the code. Is it possible
> >
> > template T swap_endian(T x)
> > {
> > char* a = reinterpret_cast(&x);
> > char* b = a + sizeof(T) - 1;
> > while (a > char tmp = *a;
> > *a++ = *b;
> > *b-- = tmp;
> > }
> > return x;
> > }
> >
> > template T host2little(T x)
> > {
> > unsigned u = 1; return (*reinterpret_cast(&u) ? x :
> > swap_endian(x));
> > }
>
> You are violating aliasing rules.
Where, exactly? Casting to char* is legit.
Andrew.
Re: help interpreting gcc 4.1.1 optimisation bug
On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> >>
> >> I'm starting to be a little suspicious about host2little(). I wonder
> >> if that's well-defined.
> >>
> >> I'm just guessing here becasue I can't see the code. Is it possible
> >
> >template T swap_endian(T x)
> >{
> >char* a = reinterpret_cast(&x);
> >char* b = a + sizeof(T) - 1;
> >while (a >char tmp = *a;
> >*a++ = *b;
> >*b-- = tmp;
> >}
> >return x;
> >}
> >
> >template T host2little(T x)
> >{
> >unsigned u = 1; return (*reinterpret_cast(&u) ? x :
> >swap_endian(x));
> >}
>
> You are violating aliasing rules. Try -fno-strict-aliasing, which
> should make the code
> work, or fix it.
Hmmm - don't grok; I'll do some googling. Compiling now with
-fno-strict-aliasing, but the manual says -O2 includes
-strict-aliasing, so what gives?
Andrew
Re: RFC: gimple tuples data structures design
Steven Bosscher wrote on 06/09/06 19:12:
> For gimple temporaries, are you planning on something different from
> the current minimal decl (tree_decl_with_vis in tree.h; needs
> re-indenting btw...)?
>
I was hoping to get away with just type, but I'm not sure if that's
possible yet.
>> /* All tree structures, including the gimple IL, derive from this base
>>structure. */
>> struct tree_base GTY(())
>> {
>> ENUM_BITFIELD(tree_code) code : 8;
>
> This will almost certainly be too small. With ObjC we already almost
> have more DEFTREECODEs than MAX_TREE_CODES. Maybe make this 16 bit
> while you're changing things in this area?
>
Yeah, we discussed this. We certainly have a lot of padding in
tree_base. I think a 16 bit code is a good idea.
> Maybe you could move some flags now already?
>
No particular reason for these flags. Just to indicate all the padding
we have. If we make code a 16-bit field, then we don't need all these
flags. In principle, I'd like to remove all of them. Initially, we
will probably just move them to tree_common.
> So there is still chain and type here, that's too bad. Ceaning that up
> is outside the scope of your project I suppose.
>
Initially, yes. We are not trying to convert everything at once. The
idea is to move into tree_common fields that we don't want to tackle
right now. ATM, we are only interested in GIMPLE statements and
assignment expressions. The goal is to have all of the GIMPLE
statements and expressions "inherit" from tree_base, and allow the front
ends to keep using the traditional tree structures if they want.
> Will these gimple_stmts
> be in containers like struct tree_statement_list_node (which does have
> chain_{next,prev} GTY markers)?
>
Yes, only in containers. The GTY maker for next and prev is probably an
oversight.
>> /* Gimple SSA names.
>>
>>This is the similar to ``tree_ssa_name'' in GENERIC
>
> Why would we have tree_ssa_name for GENERIC?
>
We don't. Aldy was just referring to the current SSA name data structure.
Re: help interpreting gcc 4.1.1 optimisation bug
On Mon, Jun 12, 2006 at 12:30:50PM +, [EMAIL PROTECTED] wrote:
> On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> > >>
> > >> I'm starting to be a little suspicious about host2little(). I wonder
> > >> if that's well-defined.
> > >>
> > >> I'm just guessing here becasue I can't see the code. Is it possible
> > >
> > >template T swap_endian(T x)
> > >{
> > >char* a = reinterpret_cast(&x);
> > >char* b = a + sizeof(T) - 1;
> > >while (a > >char tmp = *a;
> > >*a++ = *b;
> > >*b-- = tmp;
> > >}
> > >return x;
> > >}
> > >
> > >template T host2little(T x)
> > >{
> > >unsigned u = 1; return (*reinterpret_cast(&u) ? x :
> > >swap_endian(x));
> > >}
> >
> > You are violating aliasing rules. Try -fno-strict-aliasing, which
> > should make the code
> > work, or fix it.
>
> Hmmm - don't grok; I'll do some googling. Compiling now with
> -fno-strict-aliasing, but the manual says -O2 includes
> -strict-aliasing, so what gives?
Indeed, -fno-strict-aliasing makes no difference; its still broken.
>
> Andrew
Re: help interpreting gcc 4.1.1 optimisation bug
[EMAIL PROTECTED] writes:
> On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> > >>
> > >> I'm starting to be a little suspicious about host2little(). I wonder
> > >> if that's well-defined.
> > >>
> > >> I'm just guessing here becasue I can't see the code. Is it possible
> > >
> > >template T swap_endian(T x)
> > >{
> > >char* a = reinterpret_cast(&x);
> > >char* b = a + sizeof(T) - 1;
> > >while (a > >char tmp = *a;
> > >*a++ = *b;
> > >*b-- = tmp;
> > >}
> > >return x;
> > >}
> > >
> > >template T host2little(T x)
> > >{
> > >unsigned u = 1; return (*reinterpret_cast(&u) ? x :
> > >swap_endian(x));
> > >}
> >
> > You are violating aliasing rules. Try -fno-strict-aliasing, which
> > should make the code
> > work, or fix it.
>
> Hmmm - don't grok; I'll do some googling. Compiling now with
> -fno-strict-aliasing, but the manual says -O2 includes
> -strict-aliasing, so what gives?
-fno-strict-aliasing is a kludge that causes gcc to ignore type
information when generating memory accesses. This means that gcc
assumes that an object pointed to by a pointer potentially refers to
any object in your program; this has the effect of preventing many
optimizations.
If -fno-strict-aliasing fixes your problem, then you have a bug in
your code somewhere. This option is provided for compatibility with
ancient code.
Andrew.
Re: help interpreting gcc 4.1.1 optimisation bug
[EMAIL PROTECTED] writes:
> On Mon, Jun 12, 2006 at 12:30:50PM +, [EMAIL PROTECTED] wrote:
> > On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > > On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> > > >>
> > > >> I'm starting to be a little suspicious about host2little(). I wonder
> > > >> if that's well-defined.
> > > >>
> > > >> I'm just guessing here becasue I can't see the code. Is it possible
> > > >
> > > >template T swap_endian(T x)
> > > >{
> > > >char* a = reinterpret_cast(&x);
> > > >char* b = a + sizeof(T) - 1;
> > > >while (a > > >char tmp = *a;
> > > >*a++ = *b;
> > > >*b-- = tmp;
> > > >}
> > > >return x;
> > > >}
> > > >
> > > >template T host2little(T x)
> > > >{
> > > >unsigned u = 1; return (*reinterpret_cast(&u) ? x :
> > > >swap_endian(x));
> > > >}
> > >
> > > You are violating aliasing rules. Try -fno-strict-aliasing, which
> > > should make the code
> > > work, or fix it.
> >
> > Hmmm - don't grok; I'll do some googling. Compiling now with
> > -fno-strict-aliasing, but the manual says -O2 includes
> > -strict-aliasing, so what gives?
>
> Indeed, -fno-strict-aliasing makes no difference; its still broken.
Well, that is interesting! I think both Richard Guenther and I both
thought you had an aliasing problem somewhere: all those pointer casts
are something of a red flag...
OK, well, we're stuck until you can make a test case.
Andrew.
Re: help interpreting gcc 4.1.1 optimisation bug
On Mon, Jun 12, 2006 at 01:40:18PM +0100, Andrew Haley wrote:
> [EMAIL PROTECTED] writes:
> > On Mon, Jun 12, 2006 at 12:30:50PM +, [EMAIL PROTECTED] wrote:
> > > On Mon, Jun 12, 2006 at 02:21:21PM +0200, Richard Guenther wrote:
> > > > On 6/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > > >On Mon, Jun 12, 2006 at 01:01:47PM +0100, Andrew Haley wrote:
> > > > >>
> > > > >> I'm starting to be a little suspicious about host2little(). I
> wonder
> > > > >> if that's well-defined.
> > > > >>
> > > > >> I'm just guessing here becasue I can't see the code. Is it possible
> > > > >
> > > > >template T swap_endian(T x)
> > > > >{
> > > > >char* a = reinterpret_cast(&x);
> > > > >char* b = a + sizeof(T) - 1;
> > > > >while (a > > > >char tmp = *a;
> > > > >*a++ = *b;
> > > > >*b-- = tmp;
> > > > >}
> > > > >return x;
> > > > >}
> > > > >
> > > > >template T host2little(T x)
> > > > >{
> > > > >unsigned u = 1; return (*reinterpret_cast(&u) ? x :
> > > > >swap_endian(x));
> > > > >}
> > > >
> > > > You are violating aliasing rules. Try -fno-strict-aliasing, which
> > > > should make the code
> > > > work, or fix it.
> > >
> > > Hmmm - don't grok; I'll do some googling. Compiling now with
> > > -fno-strict-aliasing, but the manual says -O2 includes
> > > -strict-aliasing, so what gives?
> >
> > Indeed, -fno-strict-aliasing makes no difference; its still broken.
>
> Well, that is interesting! I think both Richard Guenther and I both
> thought you had an aliasing problem somewhere: all those pointer casts
> are something of a red flag...
Well, my point above was that -strict-aliasing is included in -O2 and
my code works fine at -O2. Only -O3 causes problems, so I didn't expect
-fno-strict-aliasing to make any difference.
>
> OK, well, we're stuck until you can make a test case.
>
Oh well. brute force it is then ;)
I'll be back with test case asap. Thanks for comments!
> Andrew.
>
Re: RFC: gimple tuples data structures design
Daniel Berlin wrote on 06/09/06 19:32:
>> /* This structure is for generic trees. */
>> struct tree_common GTY(())
>> {
>> struct tree_base base;
>> tree chain;
>> tree type;
>> union tree_ann_d *ann;
>> };
> Why is there a chain in tree_common?
>
To avoid wholesale conversion. Initially, we are only interested in
gimple statements and assignment expressions. The idea is to gradually
make all the GIMPLE expressions to inherit from tree_base. The 'chain'
field may be useful for the front-ends (which we are not interested in
messing with).
> The last time i moved value handle to a hash table, FRE/PRE got like 20%
> slower.
> So if you are going to move it, you should probably take careful
> measurements before using a hash table, *or* use an indexed array
> (either is fine by me).
>
> I assume nothing has been done about array accesses or indirect refs yet
> due to no true consensus yet?
>
No. I've been waiting for the feedback to stop. I will send a revised
design soon.
> Also, one thing to throw on your todo list about gimple
> temporaries/ssa_names is that a *lot* of places create one var per
> ssa_name for no good reason.
>
Sure. I'm hoping we can get to 1 or 2 word GIMPLE temps (just the type
and an ID). Having a symbol associated with SSA names is convenient but
we should be able to remove that dependency.
sparc elf
Hi,
I have been trying to build sparc elf executables from i386. I got
gcc,binutils and newlibc and configured them with target=sparc-elf .
Now when i got gcc and binutils working , i wrote a small program
test.c:
int main()
{
return 3;
}
i compiled it using sparc-elf-gcc -c test.c.
./sparc-elf-ld --entry=main test.o -o a.out
when i executed a.out on sparc machine it segfaulted and dumped core.
Why does this happen. This is a very small executable and everything
is static. Where i am i doing wrong.
Regards
Nik
algorithm to parse a propositional logic formula
Does anyboby know where I ccan find an algorithm to parse a propositional logic formula and obtain the associated binary tree? thanks
Re: help interpreting gcc 4.1.1 optimisation bug
[EMAIL PROTECTED] writes: > > Well, my point above was that -strict-aliasing is included in -O2 and > my code works fine at -O2. Only -O3 causes problems, so I didn't expect > -fno-strict-aliasing to make any difference. That doesn't follow at all. -O3 exposes much more information to the compiler, so it can do more optimization. If the code is incorrect, -O3 is more likely to provike problems. Andrew.
Re: Generator programs can only be built with optimization enabled?
> Paolo Bonzini writes: Paolo> So, let's please not confuse issues. I work in the GCC directory daily. Paolo> I type "make" there and it just works. You can even type "make Paolo> quickstrap" if you want: Paolo> I think this was your suggestion, and it was implemented. Typing "make" in the gcc subdirectory does not do what I expect. Also, if "make quickstrap" is implemented, you should update the "Top-Level Bootstrap" page in the GCC Wiki to document the current functionality. David
Re: Generator programs can only be built with optimization enabled?
On Mon, Jun 12, 2006 at 10:22:17AM -0400, David Edelsohn wrote: > Typing "make" in the gcc subdirectory does not do what I expect. Then could you clarify what happens, and what you expect, please? -- Daniel Jacobowitz CodeSourcery
Re: Generator programs can only be built with optimization enabled?
> Daniel Jacobowitz writes: Daniel> On Mon, Jun 12, 2006 at 10:22:17AM -0400, David Edelsohn wrote: >> Typing "make" in the gcc subdirectory does not do what I expect. Daniel> Then could you clarify what happens, and what you expect, please? The behavior prior to the top-level bootstrap changes that I and others repeatedly have mentioned in email and IRC: if I type "make cc1" in the gcc subdirectory, the build should be invoked with the appropriate options from the current build stage. In other words, if I have a completely bootstrapped compiler, change a source file, enter $objdir/gcc, and type "make cc1", I expect cc1 to be rebuilt with CFLAGS="-O2 -g". Instead, if I type "make" or "make quickstrap", the compilation uses CFLAGS=-g. Thanks, David
Re: CIL back-end
Diego Novillo wrote: > Roberto COSTA wrote on 06/12/06 03:50: > > > Every so often CIL looks to poke in the works of the mailing list, but I > > haven't been able to track the current status of the discussion on the > > topic. > > > We have started work on a bytecode representation that will initially be > used for link-time optimizations (search the archives for LTO). The > Wiki has a brief description of the cleanup work needed for it > (http://gcc.gnu.org/wiki/LinkTimeCleanups). This page has no discussion about a CIL backend. The document in which Mark has announced the LTO briefly mentions that CIL was not retained for dumping the IR, without giving an explicit reason, so I think that we need a clear position from the FSF whether such a backend is accepted to be part of GCC. We will also have to consider what these people might bring in terms of compiler optimizations to GCC, as they want a highly optimized CIL bytecode. Finally I think that we could discuss how to implement a CIL generator without duplicating the work needed for dumping the IRs to file. Sebastian
Re: CIL back-end
Sebastian Pop wrote on 06/12/06 12:40: > This page has no discussion about a CIL backend. > Note that I never said 'CIL'. I specifically said 'bytecode representation'. The work being done for LTO will have some points in common with an effort to build a CIL backend. > The document in which Mark has announced the LTO briefly mentions > that CIL was not retained for dumping the IR, without giving an > explicit reason, so I think that we need a clear position from the > FSF whether such a backend is accepted to be part of GCC. > Yes, that's true. If anyone is interested in contributing a CIL backend, the FSF would have to approve it. That's not a decision we can make in this list.
Re: CIL back-end
Diego Novillo wrote: > > The document in which Mark has announced the LTO briefly mentions > > that CIL was not retained for dumping the IR, without giving an > > explicit reason, so I think that we need a clear position from the > > FSF whether such a backend is accepted to be part of GCC. > > > Yes, that's true. If anyone is interested in contributing a CIL > backend, the FSF would have to approve it. That's not a decision we can > make in this list. Could one of the SC people bring this question one level up? Thanks, Sebastian
Re: CIL back-end
On Jun 12, 2006, at 9:56 AM, Sebastian Pop wrote: Could one of the SC people bring this question one level up? I don't know if this is relevant at this point but GCC did have at one point did have a Java byte code outputter but it was removed on the request of RMS. -- Pinski
Re: CIL back-end
Diego Novillo wrote: Sebastian Pop wrote on 06/12/06 12:40: This page has no discussion about a CIL backend. Note that I never said 'CIL'. I specifically said 'bytecode representation'. The work being done for LTO will have some points in common with an effort to build a CIL backend. The document in which Mark has announced the LTO briefly mentions that CIL was not retained for dumping the IR, without giving an explicit reason, so I think that we need a clear position from the FSF whether such a backend is accepted to be part of GCC. Yes, that's true. If anyone is interested in contributing a CIL backend, the FSF would have to approve it. That's not a decision we can make in this list. It looks like you don't assume such an approval as granted... may I ask you why? To avoid misunderstandings, I want to make clear that the intent of my post is to propose a CIL back-end, not to suggest CIL as a bytecode internal representation for link-time optimizations, nor to use CIL to bump GCC internal representation and to circumvent GPL restrictions. (Of course, if there are points in common between a CIL back-end and efforts to build a bytecode representation, it may interesting to share the infrastructure, or parts of it). What I need is to produce highly optimized CIL from plain C code, nothing more, nothing less. In this sense, such a CIL back-end looks to me not much different from Java back-end that, to the best of my knowledge, is already included in gjc. Roberto
Re: help interpreting gcc 4.1.1 optimisation bug
On Jun 12, 2006, at 5:45 AM, [EMAIL PROTECTED] wrote: Well, my point above was that -strict-aliasing is included in -O2 and my code works fine at -O2. Only -O3 causes problems, so I didn't expect -fno-strict-aliasing to make any difference. Code in violation of the aliasing rules can appear to work at any optimization level.
Re: CIL back-end
Roberto COSTA wrote: > Diego Novillo wrote: >> Sebastian Pop wrote on 06/12/06 12:40: >> >> >>> This page has no discussion about a CIL backend. >>> >> Note that I never said 'CIL'. I specifically said 'bytecode >> representation'. The work being done for LTO will have some points in >> common with an effort to build a CIL backend. >> >> >>> The document in which Mark has announced the LTO briefly mentions >>> that CIL was not retained for dumping the IR, without giving an >>> explicit reason, so I think that we need a clear position from the >>> FSF whether such a backend is accepted to be part of GCC. >>> >> Yes, that's true. If anyone is interested in contributing a CIL >> backend, the FSF would have to approve it. That's not a decision we can >> make in this list. > > It looks like you don't assume such an approval as granted... may I ask > you why? Because they have a history of not granting such things, believing that it serves to hinder, not further, the goal of free software. (This is not necessarily my viewpoint, i'm just answering your question). Really, you'd need to take this up with the SC, and they'll take it up with the FSF. --Dan
Re: algorithm to parse a propositional logic formula
On Mon, Jun 12, 2006 at 03:20:20PM +0200, Riccardo wrote: > Does anyboby know where I ccan find an algorithm to parse a propositional > logic formula and obtain the associated binary tree? thanks Please don't ask questions like that on this list.
Re: CIL back-end
On Mon, Jun 12, 2006 at 12:00:36PM -0400, Daniel Berlin wrote: > Roberto COSTA wrote: > > It looks like you don't assume such an approval as granted... may I ask > > you why? > > Because they have a history of not granting such things, believing that > it serves to hinder, not further, the goal of free software. > > Really, you'd need to take this up with the SC, and they'll take it up > with the FSF. You might as well cut out the middle man and make your case directly to RMS. RMS has opposed mechanisms that allow for proprietary front ends or proprietary back ends to be added to GCC; C output, bytecode output, etc. He has his reasons; he believes (with evidence) that the only reason we have a free C++ compiler and a free Objective-C compiler was that there wasn't a way for the original authors to make them proprietary but still use GCC to do the bulk of the optimization and code generation. The SC has no say about this issue. Please don't argue about it on this list, as the man you are arguing with does not read it.
Re: Generator programs can only be built with optimization enabled?
Paolo Bonzini wrote: > This was caused by: > 2006-01-22 Zack Weinberg <[EMAIL PROTECTED]> > > * genautomata.c: Include vec.h, not varray.h. > > > The problem that Mark reported happens because (since always) the CFLAGS > of the gcc directory are just "-g", not "-O2 -g". Optimized builds have > (since always) been done only because the toplevel overrides the "-g" > CFLAGS. So, when you type "make" in the gcc directory, it triggers a > non-optimized build of everything (generator programs, compiler, > driver), which in turn triggers PR18058. I think that, after Zack's change, the generator programs that include rtl.h should be linked with build/vec.o. That may not be necessary when optimizing, but it would avoid this problem. Do you agree? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: sparc elf
2006/6/12, Niklaus <[EMAIL PROTECTED]>:
int main()
{
return 3;
}
i compiled it using sparc-elf-gcc -c test.c.
./sparc-elf-ld --entry=main test.o -o a.out
when i executed a.out on sparc machine it segfaulted and dumped core.
I guess 'cos you set entrypoint=main instead of __start or whatever it
is called.
You need to load in crtbegin.o (it may be called crt0.o), which
contains the correct entry point and calls main() and cleans up after
it, not just dive straight into main().
I wuold guess your segfault was caused by whatever non-existent code
your main() "returned" to :) You could just call _exit(3) instead
probably.
Or use "sparc-elf-gcc test.c", even better...
M
Re: CIL back-end
On Mon, 12 Jun 2006 09:50:13 +0200, Roberto COSTA <[EMAIL PROTECTED]> said: > Hello, > > I'm working for an R&D organization of STMicroelectronics. Within our > team we have decided to write a gcc back-end that produces CIL binaries > (compliant with ECMA specification, see > http://www.ecma-international.org/publications/standards/Ecma-335.htm). > Our main motivation is the ability to produce highly-optimized CIL > binaries out of plain C code (and C++ in the future), and possibly to > add some optimizations to improve, if needed, the quality of the > generated code. It seems that there's a Summer of Code student working on the exact same item: http://code.google.com/soc/mono/about.html Perhaps you could collaborate with him, or (as I believe the Summer of Code rules might require) build off his work after it gets submitted. I'd suggest you contact the Mono project about it. -- Suicide is simply a case of mistaken identity.
Re: CIL back-end
On Mon, 12 Jun 2006 09:50:13 +0200, Roberto COSTA <[EMAIL PROTECTED]> said: > Hello, > > I'm working for an R&D organization of STMicroelectronics. Within our > team we have decided to write a gcc back-end that produces CIL binaries > (compliant with ECMA specification, see > http://www.ecma-international.org/publications/standards/Ecma-335.htm). > Our main motivation is the ability to produce highly-optimized CIL > binaries out of plain C code (and C++ in the future), and possibly to > add some optimizations to improve, if needed, the quality of the > generated code. It seems that there's a Summer of Code student working on the exact same item: http://code.google.com/soc/mono/about.html Perhaps you could collaborate with him, or (as I believe the Summer of Code rules might require) build off his work after it gets submitted. I'd suggest you contact the Mono project about it. -- Suicide is simply a case of mistaken identity.
Re: CIL back-end
Ori Bernstein wrote: Perhaps you could collaborate with him, or (as I believe the Summer of Code rules might require) build off his work after it gets submitted. I'd suggest you contact the Mono project about it. How could SoC rules in any way restrict what third parties can do?
Re: CIL back-end
On Mon, 12 Jun 2006 13:26:41 -0400, Robert Dewar <[EMAIL PROTECTED]> said: > How could SoC rules in any way restrict what third > parties can do? It would restrict whether he could collaborate with a 3rd party. -- When does summertime come to Minnesota, you ask? Well, last year, I think it was a Tuesday.
Re: CIL back-end
On Mon, Jun 12, 2006 at 01:36:35PM -0500, Ori Bernstein wrote: > On Mon, 12 Jun 2006 13:26:41 -0400, Robert Dewar <[EMAIL PROTECTED]> said: > > > How could SoC rules in any way restrict what third > > parties can do? > > It would restrict whether he could collaborate with a 3rd party. Free software is all about collaboration with third parties, as I'm sure that the SoC people are well aware.
Re: CIL back-end
On Mon, 12 Jun 2006 10:36:49 -0700, Joe Buck <[EMAIL PROTECTED]> said: > Free software is all about collaboration with third parties, as I'm > sure that the SoC people are well aware. True. I'd still suggest asking and making sure, since I know for a fact that students aren't allowed to work together on a single project from my application to SoC. (mainly to prevent blame-shifting, or an incompetent person screwing over another student.) Either way, the point is that the work is being done, and that it might be a good idea to team up with whoever is doing it now, after making sure it doesn't cause any issues. I suggest we leave this sub-thread be. (note to self: use the email address I actually subscribed to the list with)
Re: CIL back-end
Ori Bernstein wrote: > On Mon, 12 Jun 2006 10:36:49 -0700, Joe Buck <[EMAIL PROTECTED]> said: > >> Free software is all about collaboration with third parties, as I'm >> sure that the SoC people are well aware. > > True. I'd still suggest asking and making sure, since I know for a fact that > students aren't allowed to work together on a single project from my > application to SoC. This isn't quite right. We don't allow students to submit a group application. We do allow people to work on the same project, just different parts of it. We just leave it up to the orgs, not the students. Anyway, feel free to collaborate. --Dan
Re: Errors while building bootstrap GCC for "mipsisa32-elf" target
Monika Sapra wrote: I am not able to understand, why the checkout source of GCC is so large in size? I am using the following command to checkout source: See the info in the wiki. It talks about ways to reduce disk space. http://gcc.gnu.org/wiki/SvnHelp -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: sparc elf
Niklaus wrote: when i executed a.out on sparc machine it segfaulted and dumped core. On what kind of sparc machine? It sounds like you tried to run the code on a sparc-solaris or sparc-linux machine, which won't work. sparc-elf code can only be run on bare hardware. Try building a cross gdb, and then using the sparc-elf-run simulator. You can also try using the sparc-elf-gdb, but you will have to read the docs to learn how to do it. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: help interpreting gcc 4.1.1 optimisation bug
Ok, I think I have tracked this down to having broken the aliasing
rules, and for the sake of completeness, here was the problem:
Recall that the (big picture) code works fine at -O2, but fails at
-O3. The problem seemed to stem from this inline assembly function:
void longcpy(long* _dst, long* _src, unsigned _numwords)
{
asm volatile (
"cld \n\t"
"rep \n\t"
"movsl \n\t"
// Outputs
:
// Inputs
: "S" (_src), "D" (_dst), "c" (_numwords)
// Clobbers
: "cc", "memory"
);
}
My interpretation of the problem:
_dst, _src and _numwords will get clobbered, but I didn't
care. Now if the compiler inlines the function, and later re-uses the
register-cached values assuming them to be intact, then it all goes
horribly wrong.
But, if I specify the outputs like this:
// Outputs
: "=&S" (_src), "=&D" (_dst), "=&c" (_numwords)
the the compiler is warned that the registers are clobbered and now
contain some (undefined and unused) return values, and won't expect
_src, _dst and _numwords to be intact in esi, edi, ecx.
Now everything works fine at -O3. However, I really don't understand
the '&' early clobber constraint modifer. What use is it?
The Gcc inline assembly howto seems woefully out of date. (Indeed in
several of its examples, it would simply add esi, edi and ecx to the
clobber list, but that seems illegal now; anything mentioned in inputs
or outputs cannot appear in the clobber list it seems.)
Thanks,
Andrew Walrond
Re: help interpreting gcc 4.1.1 optimisation bug
[EMAIL PROTECTED] writes:
> void longcpy(long* _dst, long* _src, unsigned _numwords)
> {
> asm volatile (
> "cld \n\t"
> "rep \n\t"
> "movsl \n\t"
> // Outputs
> :
> // Inputs
> : "S" (_src), "D" (_dst), "c" (_numwords)
> // Clobbers
> : "cc", "memory"
> );
> }
>
> My interpretation of the problem:
>
> _dst, _src and _numwords will get clobbered, but I didn't
> care. Now if the compiler inlines the function, and later re-uses the
> register-cached values assuming them to be intact, then it all goes
> horribly wrong.
>
> But, if I specify the outputs like this:
>
> // Outputs
> : "=&S" (_src), "=&D" (_dst), "=&c" (_numwords)
>
> the the compiler is warned that the registers are clobbered and now
> contain some (undefined and unused) return values, and won't expect
> _src, _dst and _numwords to be intact in esi, edi, ecx.
Probably better to say that these are read-write operands, using the
'+' constraint.
> Now everything works fine at -O3. However, I really don't understand
> the '&' early clobber constraint modifer. What use is it?
It is needed for assembly code which has both outputs and inputs, and
which includes more than one instruction, such that at least one of
the outputs is generated by an instruction which runs before another
instruction which requires one of the inputs. The '&' constraint
tells gcc that some of the output operands are produced before some of
the input operands are used. gcc will then avoid allocating the input
and output operands to the same register.
Ian
GCC 4.2 emitting static template constants as global symbols?
Hi,
I have some software that uses the BOOST matrix library UBLAS (1.33.1).
With GCC 4.1.1 this software compile fine (Debian Linux system - GNU
ld). However, with GCC 4.2 I get lots of errors, but I am not sure if
this is a bug or not:
substitution.o:(.data+0x0): multiple definition of
`_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'
alignment.o:(.data+0x0): first defined here
This is from the definition of a static const member of a template class
in boost/numeric/ublas/functional.hpp:
template
struct scalar_divides_assign:
public scalar_binary_assign_functor {
... stuff ...
};
template
const bool scalar_divides_assign::computed = true;
For some reason, GCC 4.2, but not 4.1 actually emits this constant in
the global data section. With 4.2:
$ nm alignment.o | grep divides
0180 t
_GLOBAL__I__ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
D
_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
With 4.1 neither of these two symbols (or is it one symbol, mentioned
twice?) is emitted.
So, is this a non-bug, or should I submit this to bugzilla?
thanks!
-BenRI
Re: GCC 4.2 emitting static template constants as global symbols?
Benjamin Redelings <[EMAIL PROTECTED]> writes: > substitution.o:(.data+0x0): multiple definition of > `_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE' I can't make sense of that as a mangled name. It has template parameter references but no template definition. That suggests that it is purely abstract. But we shouldn't have a symbol for an abstract object. So this looks like a bug to me. Ian
libsupc++.a(eh_globals.o): In function `__gnu_internal::get_global()': undefined reference to `___tls_get_addr'
Hi, I've tried to build openoffice using gcc-4.1.0, but failed with the following message: Building project store = /usr/src/rpm/BUILD/OOB680_m5/store/source - /usr/src/rpm/BUILD/OOB680_m5/store/util -- Making: ../unxlngi6.pro/lib/libstore.so.3 g++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-rpath,'$ORIGIN' "-Wl,-hlibstore.so.3" -shared -Wl,-O1 -Wl,--version-script ../unxlngi6.pro/misc/store_store.map -L../unxlngi6.pro/lib -L../lib -L/usr/src/rpm/BUILD/OOB680_m5/solenv/unxlngi6/lib -L/usr/src/rpm/BUILD/OOB680_m5/solver/680/unxlngi6.pro/lib -L/usr/src/rpm/BUILD/OOB680_m5/solenv/unxlngi6/lib -L/usr/lib -L/usr/jre/lib/i386 -L/usr/jre/lib/i386/client -L/usr/jre/lib/i386/native_threads -L/usr/X11R6/lib -L/usr/lib/firefox-1.5.0.1 ../unxlngi6.pro/slo/store_version.o ../unxlngi6.pro/slo/store_description.o -o ../unxlngi6.pro/lib/libstore.so.3 ../unxlngi6.pro/slo/object.o ../unxlngi6.pro/slo/memlckb.o ../unxlngi6.pro/slo/filelckb.o ../unxlngi6.pro/slo/storbase.o ../unxlngi6.pro/slo/storcach.o ../unxlngi6.pro/slo/stordata.o ../unxlngi6.pro/slo/storlckb.o ../unxlngi6.pro/slo/stortree.o ../unxlngi6.pro/slo/storpage.o ../unxlngi6.pro/slo/store.o -luno_sal -lsupc++ -lgcc_s -ldl -lpthread -lm /usr/lib/libsupc++.a(eh_globals.o): In function `__gnu_internal::get_global()': : undefined reference to `___tls_get_addr' collect2: ld 返回 1 dmake: Error code 1, while making '../unxlngi6.pro/lib/libstore.so.3' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /usr/src/rpm/BUILD/OOB680_m5/store/util dmake: Error code 1, while making 'build_instsetoo_native' What's the problem? Thanks yxx
