Re: Preserving bootstrap with non-GCC compilers

[Eric Botcazou]

> You just have to write the test in the toplevel configure.in, and place
> it just before the AC_SUBST(stage1_cflags).

Thanks!

> The maintainers may think it different, but I won't see anything wrong
> in having a simpler
>
>if test "$GCC" = yes; then
>  stage1_cflags="${stage1_cflags} -fkeep-inline-functions"
>fi
>
> since most versions of GCC (at least 2.7.2 which is the oldest I ever
> used, around 1998 on RH5.2) have the flag.

I'm not an autoconf guru but this test is trivial to write so I'd rather play 
by the most strict rules.

-- 
Eric Botcazou

gcc-4.1.0 hangs with -pipe -v --help

[René Rebe]

Hi all,

gcc-4.1.0 hangs when called with  -pipe -v --help.

This interesting combinations of argument pops up during compilation
of xemacs, which invokes gcc -v --help during configure and our
build environment injects (among others) -pipe.

Yours,

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.t2-project.org
+49 (0)30  255 897 45

Re: gcc-4.1.0 hangs with -pipe -v --help

[Andreas Schwab]

René Rebe <[EMAIL PROTECTED]> writes:

> gcc-4.1.0 hangs when called with  -pipe -v --help.

I can't reproduce that on ia64-linux.  Please see
 for how to report bugs.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: gcc-4.1.0 hangs with -pipe -v --help

[René Rebe]

Hi,

On Sunday 05 March 2006 12:12, Andreas Schwab wrote:
> René Rebe <[EMAIL PROTECTED]> writes:
> 
> > gcc-4.1.0 hangs when called with  -pipe -v --help.
> 
> I can't reproduce that on ia64-linux.  Please see
>  for how to report bugs.

thanks for this valueable feedback, at least it works for you.

Of course I could be more verbose but just wanted to report my
shock from this sunday morning discovery, e.g. it could be
some deeper problem as the top-level /include header install
issue I discovered shortly before the 4.1.0 release.

That said I'm on x86-64-t2-linux-gnu, here is an strace:

strace -e process -f -o log gcc -pipe -v --help 

24998 execve("/usr/bin/gcc", ["gcc", "-pipe", "-v", "--help"], [/* 30 vars */]) 
= 0
24998 arch_prctl(ARCH_SET_FS, 0x2ade66d0) = 0
24998 vfork()   = 24999
24998 vfork()   = 25000
24998 wait4(24999,  
24999 execve("/usr/libexec/gcc/x86_64-t2-linux-gnu/4.1.0/cc1", 
["/usr/libexec/gcc/x86_64-t2-linux"..., "-quiet", "-v", "help-dummy", "-quiet", 
"-dumpbase", "help-dummy", "-mtune=k8", "-auxbase", "help-dummy", "-version", 
"--help", "-o", "-"], [/* 32 vars */] 
25000 
execve("/usr/lib64/gcc/x86_64-t2-linux-gnu/4.1.0/../../../../x86_64-t2-linux-gnu/bin/as",
 ["/usr/lib64/gcc/x86_64-t2-linux-g"..., "-V", "-Qy", "--help", "-o", 
"/tmp/ccMyO4oo.o", "-"], [/* 32 vars */]) = 0
24999 <... execve resumed> )= 0
25000 arch_prctl(ARCH_SET_FS, 0x2ade66d0 
24999 arch_prctl(ARCH_SET_FS, 0x2ade66d0 
25000 <... arch_prctl resumed> )= 0
24999 <... arch_prctl resumed> )= 0
25000 exit_group(0) = ?
24999 --- SIGINT (Interrupt) @ 0 (0) ---
24998 <... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGINT}], 0, NULL) 
= 24999

So maybe it is a problem in combination with some specific binutils
version. I'm still looking into the details.

gcc version 4.1.0
# as -v
GNU assembler version 2.16.91.0.5 (x86_64-t2-linux-gnu) using BFD version 
2.16.91.0.5 20051219

Oh - wait, "as -v" alone already hangs ... ?

Yours,
-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.t2-project.org
+49 (0)30  255 897 45

Re: gcc-4.1.0 hangs with -pipe -v --help

[René Rebe]

On Sunday 05 March 2006 12:27, René Rebe wrote:
> Hi,
> 
> On Sunday 05 March 2006 12:12, Andreas Schwab wrote:
> > René Rebe <[EMAIL PROTECTED]> writes:
> > 
> > > gcc-4.1.0 hangs when called with  -pipe -v --help.
> > 
> > I can't reproduce that on ia64-linux.  Please see
> >  for how to report bugs.
> 
> thanks for this valueable feedback, at least it works for you.
> 
> Of course I could be more verbose but just wanted to report my
> shock from this sunday morning discovery, e.g. it could be
> some deeper problem as the top-level /include header install
> issue I discovered shortly before the 4.1.0 release.
> 
> That said I'm on x86-64-t2-linux-gnu, here is an strace:
> 
> strace -e process -f -o log gcc -pipe -v --help 
> 
> 24998 execve("/usr/bin/gcc", ["gcc", "-pipe", "-v", "--help"], [/* 30 vars 
> */]) = 0
> 24998 arch_prctl(ARCH_SET_FS, 0x2ade66d0) = 0
> 24998 vfork()   = 24999
> 24998 vfork()   = 25000
> 24998 wait4(24999,  
> 24999 execve("/usr/libexec/gcc/x86_64-t2-linux-gnu/4.1.0/cc1", 
> ["/usr/libexec/gcc/x86_64-t2-linux"..., "-quiet", "-v", "help-dummy", 
> "-quiet", "-dumpbase", "help-dummy", "-mtune=k8", "-auxbase", "help-dummy", 
> "-version", "--help", "-o", "-"], [/* 32 vars */] 
> 25000 
> execve("/usr/lib64/gcc/x86_64-t2-linux-gnu/4.1.0/../../../../x86_64-t2-linux-gnu/bin/as",
>  ["/usr/lib64/gcc/x86_64-t2-linux-g"..., "-V", "-Qy", "--help", "-o", 
> "/tmp/ccMyO4oo.o", "-"], [/* 32 vars */]) = 0
> 24999 <... execve resumed> )= 0
> 25000 arch_prctl(ARCH_SET_FS, 0x2ade66d0 
> 24999 arch_prctl(ARCH_SET_FS, 0x2ade66d0 
> 25000 <... arch_prctl resumed> )= 0
> 24999 <... arch_prctl resumed> )= 0
> 25000 exit_group(0) = ?
> 24999 --- SIGINT (Interrupt) @ 0 (0) ---
> 24998 <... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGINT}], 0, 
> NULL) = 24999
> 
> So maybe it is a problem in combination with some specific binutils
> version. I'm still looking into the details.
> 
> gcc version 4.1.0
> # as -v
> GNU assembler version 2.16.91.0.5 (x86_64-t2-linux-gnu) using BFD version 
> 2.16.91.0.5 20051219
> 
> Oh - wait, "as -v" alone already hangs ... ?

Ouhm - too fast, as alone does not hang as called by gcc with:
as -V -Qy --help -o /tmp/cchq8w5q.o -

Yours,

-- 
René Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany)
http://www.exactcode.de | http://www.t2-project.org
+49 (0)30  255 897 45

Re: does gcc 4.1 generate "faster" binaries than earlier gcc versions?

[Tomasz Chmielewski]

David Daney wrote:

Tomasz Chmielewski wrote:

Perhaps the question is a bit silly, but I thought I'd ask it anyway.

I'm compiling some software for a Linux/uClibc on a mipsel platform.

Right now I'm using gcc 3.4.4 to do both native and cross-compilation.

A while ago gcc 4.1 was released, and boasts many optimizations.


As the mipsel devices I use are rather slow - here comes the point of 
my question: will binaries I compile with gcc 4.1 be faster than these 
compiled with 3.4.4?


I don't really care about compilation time; I'm only concerned with 
the speed of the binaries made with gcc 3.4.4 and 4.1 (i.e., will gzip 
compiled with gcc 4.1 compress a given file faster than gzip 
compressed with gcc 3.4.4).


Both gcc-3.4.4 and 4.1 are available to you, so in theory you could 
answer this question empirically (assuming that you also have the gzip 
sources and a file you could test the resulting gzip executable on).


Well, now I have only gcc-3.4.4 available for mipsel/uClibc; I don't 
have gcc-4.1 as a cross-compiler nor a native compiler.
As creating a cross-compiler is not an easy process, I'd have to compile 
a native 4.1 gcc.
And compiling gcc-4.1 on this mipsel device could take a week or so I 
guess (provided everything goes well after I type "make ", which 
is not always the case).

Hence my question.


You don't say what version of Binutils you are using.  But with recent 
snapshots of Binutils you can use '-Wa,-mno-shared, -ffunction-sections 
-fdata-sections -Wl,--gc-sections' to good effect on mips[el]-linux.


I'm using binutils 2.16.1.
Does it still apply here?


--
Tomasz Chmielewski
WPKG - http://wpkg.org
Software deployment with Samba

A bug ( ? ) and a question

[Nieuwenhuizen, JK]

Dear Sirs,

I use the gcc 3.3.5 20050117 prerelease that came with SuSe 10 and have a
problem and a question.

The problem first:

When debugging programs like this:

quote
-

using namespace std;

#include 
#include 


class Nwh {
char Firstname [12];
int age;
public:

Nwh ( char * Firstname_, int age_ );
}; // class Nwh {

Nwh :: Nwh ( char * Firstname_, int age_ ) {
strcpy ( Firstname, Firstname_ );
age = age_;
} // Nwh :: Nwh ( char * Firstname_, int age_ ) {


int main ( ) {
Nwh Me ( "Hans", 15 );
cout << "Done";
return 1;
} // int main ( ) {

unquote
---


I can put a breakpoint in the subprogram, gdb says it has been put, but it
never stops there, and stepping through the program I see it pass my break. Of
course I collided to it in more complicated sources.

---

My problem is this:

Stroustrup: The C++ ... is very cumbersome to understand after chapter 20 or
so. I frequently have the problem to read ( sequence of charstrings, integers
and doubles ) as lines from a file built by some other program or by myself as
a form in textmode. `sscanf` has always been a stepchild for C and C++, and
the debugger handles it terribly. Integers and doubles read correctly by
`sscanf ( s+60, "%lf", Myint )` are OK when printed ( `cout << ...` ), but gdb
gives them as e.g. 3.43567655+345.

Stroustrup ch 20 and 21 give very little information on sprintf, and only
mentions sscanf once. On internet Google search on "C++ tutorial sstream"
gives > 800 hits, but only three really on sstreams and 1, maybe 2 can be
used.

But I have, as said, to read from a file ( `is.getline ( line, 200 )` ) a line
formatted as an 2 integers from position 10, resp 20, a string on positions 30
- 70, and a number of doubles at well-defined positions after that.

The string may include spaces, and that is the problem since a stringstream
thinks it has done what I asked for as soon as it finds a space, so I have to
tell him that he should read all 40 chars, no matter the contents are and then
start reading the trailing doubles. In the sources I can't find the
solution. setw(40) does not help me out. So I need some formatting directives
for sstream, such as `an integer from positions 1 to 10; possibly another
integer from positions 11 - 20; a string of chars, including spaces from
positions 30 - 70; ...' .

I have been looking in the gnu.org/onlinedocs manuals, but found nothing like
''.

Can you please  tell me how to solve my problem?

A second question is: How must I interpret the avalanche of @'s in
/usr/include/c++/3.3.5/ files?

If you find in my internetsite a reason for cooperation, I will be happy to
discuss that. In these days I make mainly diskutilities like signalling
double, triple, quadruple, ... files on 500 GB background memory, a standard
format for all kinds of textfiles etc.

Nieuwenhuizen, J.K.
2006-03-05T15:10

-- 
-
Prof. Ir. J.K. Nieuwenhuizen   email:  [EMAIL PROTECTED]
dom Paul Bellotweg 8internet: www.nieuwenhuizen-jk.nl
5624 KZ Eindhoven
Netherlands Tel :[{00xx|0}40] 2442226
-

GCC 4.0.3 RC1

[Mark Mitchell]

GCC 4.0.3 RC1 is available here:

ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303

Please download and test!

As always, please report problems via Bugzilla, adding me to the CC:
list for the bug report.  Because this is a maintenance release for
4.0.x, problems that also exist in previous 4.0.x releases probably will
not be considered showstoppers, but they should still be reported.

I'm sorry that it's taken me a while to get the prerelease announced.
One of the causes is that the 4.0 gcc_release script was still using
CVS, I had to make sure that upgrading the script to the 4.1 version
would work.  Joseph Myers helped me with that process.  In any case,
it's certainly a risk to change the release script on a branch, so there
is certainly the possibility that some packaging problem has been
introduced.  That makes it especially important that you test the actual
prerelease tarballs on the FTP site.  The modified release script has
not been checked in, but will be shortly.

Assuming that there are no major problems, I expect the final release in
the middle part of next work.

Thanks,

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Question on loop.c removal

[Richard Kenner]

Forgive my ignorance, but I'm confused as to what pass now handles loop
invariants that are created at the tree->RTL level.  For example, if you have
X + C for C too large to be in the add insn on a machine.

Re: Question on loop.c removal

[Andrew Pinski]

On Mar 5, 2006, at 1:00 PM, Richard Kenner wrote:


Forgive my ignorance, but I'm confused as to what pass now handles loop
invariants that are created at the tree->RTL level.  For example, if 
you have

X + C for C too large to be in the add insn on a machine.



A new RTL pass called move loop invariant was added back in the 3.4 era 
and

was turned on before the removal of loop.c.

-- Pinski

Re: A bug ( ? ) and a question

[Mike Stump]

First, let me say this is the wrong list for how to program in C++,  
comp.lang.c++ would be better, or even comp.lang.c would be better.   
gcc-help would the a second choice.


On Mar 5, 2006, at 8:47 AM, Nieuwenhuizen, JK wrote:

cout << "Done";


This doesn't output anything immediately.  Either use "Done\n" or use  
flush.  Any decent book should explain this.  Alternatively, use  
write.  You can see any UNIX C programming book for the gory details  
of stdio buffering.


I can put a breakpoint in the subprogram, gdb says it has been put,  
but it
never stops there, and stepping through the program I see it pass  
my break. Of

course I collided to it in more complicated sources.


b main, run, either it stops at main, or it doesn't.  If it doesn't,  
then gdb is busted, report the bug to gdb.  If it does, then you're  
set.  You can step by instructions (si) and lines (s) and at any  
point of interest, you can print out the pc, say with x/1i $pc, and  
say b on that line and rerun the program and it will stop at  
the point, or gdb is busted.  Then you can compare those pc values to  
the values when you break on a particular line, they should be the  
same at some point.  If you optimize, you'll just have to gain  
experience on how the code is transformed and what it means to  
debugging, that's kinda beyond the scope of this email, use machine  
instruction break points and things like x/30i $pc to see where you  
are and what its doing.  If you can, don't optimize, it will provide  
an easier to understand debugging experience.



 `sscanf` has always been a stepchild for C and C++


I don't recall reading that in the standard, can you provide a  
quote?  I kinda like sscanf anytime I need to do that.  I like scan  
over << most of the time.



and the debugger handles it terribly.


Gosh, I've never had a problem with it in the debugger.


Integers and doubles read correctly by
`sscanf ( s+60, "%lf", Myint )` are OK when printed ( `cout  
<< ...` ), but gdb

gives them as e.g. 3.43567655+345.


You'd have to report gdb issues to a gdb list:

mrs $ cat t.cc
#include 

double d;

main() {
  sscanf ("3.1415", "%lf", &d);
  printf ("%f\n", d);
  asm ("nop");
}
mrs $ g++ t.cc -g
mrs $ gdb a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-456) (Thu Feb  9 06:00:45  
GMT 2006)

Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and  
you are
welcome to change it and/or distribute copies of it under certain  
conditions.

Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for  
details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols  
for shared libraries  done


(gdb) b main
Breakpoint 1 at 0x29ac: file t.cc, line 6.
(gdb) run
Starting program: /private/tmp/a.out
Reading symbols for shared libraries .. done

Breakpoint 1, main () at t.cc:6
6 sscanf ("3.1415", "%lf", &d);
(gdb) list
1   #include 
2
3   double d;
4
5   main() {
6 sscanf ("3.1415", "%lf", &d);
7 printf ("%f\n", d);
8 asm ("nop");
9   }
(gdb) b 8
Breakpoint 2 at 0x2a10: file t.cc, line 8.
(gdb) cont
Continuing.
3.141500

Breakpoint 2, main () at t.cc:8
8 asm ("nop");
(gdb) p d
$1 = 3.14150002
(gdb) quit
The program is running.  Exit anyway? (y or n) y

If you can reproduce the above, then you should pursue this as a bug  
in gdb.  If you can, then it looks like you can stop in the debugger  
and print out doubles at least in the debugger.



Stroustrup ch 20 and 21 give very little information on sprintf


man sprintf will provide lots of details on sprintf.  Any decent book  
on C should give details, google should give lots of detail too.  A  
quick count shows 1,990,000 things on google, the first one looked  
fine to me.



and only mentions sscanf once.


google found 730,000 things, again, the first one looked fine.


On internet Google search on "C++ tutorial sstream"
gives > 800 hits, but only three really on sstreams and 1, maybe 2  
can be

used.


Get a line, then crack it.  If you get the line into a string, you  
can use string to crack it.  Once cracked, you can use atoi, sscanf  
or other such routines to crack out the data.


But I have, as said, to read from a file ( `is.getline ( line, 200 ) 
` ) a line
formatted as an 2 integers from position 10, resp 20, a string on  
positions 30

- 70, and a number of doubles at well-defined positions after that.


Yes, but you provide no details on that.  I'd use fgets, validate the  
line length ("\n" must be last or your screwed (not done reading the  
current line), then validate the contents of the line, then sscan  
them, call me weird.  If you want help with a specific problem, show  
a specific program that shows that problem, then the input to the  
program, and what you see (from the debugger).  By omitting details  
you omit the chance for people to help you.


The str

Re: A bug ( ? ) and a question

[Mike Stump]

On Mar 5, 2006, at 11:15 AM, Mike Stump wrote:
The string is a bit trickier, strncpy (newbuf, buf+30, 40); newbuf 
[70] = 0;


[40] = 0; I meant of course.

Re: does gcc 4.1 generate "faster" binaries than earlier gcc versions?

[David Daney]

Tomasz Chmielewski wrote:

David Daney wrote:

You don't say what version of Binutils you are using.  But with recent 
snapshots of Binutils you can use '-Wa,-mno-shared, 
-ffunction-sections -fdata-sections -Wl,--gc-sections' to good effect 
on mips[el]-linux.



I'm using binutils 2.16.1.
Does it still apply here?



-Wa,-mno-shared will work 2.16.1, --gc-sections will not.

David Daney

Re: GCC 4.0.3 RC1

[Ulrich Weigand]

Mark Mitchell wrote:

> GCC 4.0.3 RC1 is available here:
> 
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.3-20060303
> 
> Please download and test!

Looking good on s390(x)-ibm-linux:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00289.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00290.html

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  [EMAIL PROTECTED]

when does Optimization happen....

[sean yang]

I understand that gcc -On happens before generating assembly code (.s), is 
it correct?

#gcc -S main.c; gcc -o a.out main.s (here without optimization)
#gcc -O2 -S main.c; gcc -o a1.out main.s (here with optimization of O2)

But some optimization, such as inlining, may require cross compilation-unit 
(i.e, cross file) information.  It seems that these kind of optization is 
better to be handled at link time (thus, cross compilation units info is 
available).


Can someone give an explanation how gcc hanle this internally? Many thanks

_
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: GCC-3.4.6 release status

[Ulrich Weigand]

Gabriel Dos Reis wrote:

>A pre-release of GCC-3.4.6 is available at
> 
>   ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.6-20060301/
> 
> 
> Please download and test.

This looks fine for s390(x)-ibm-linux:
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00291.html
http://gcc.gnu.org/ml/gcc-testresults/2006-03/msg00292.html

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  [EMAIL PROTECTED]

Coverity Open Source Defect Scan of gcc

[Ben Chelf]

Hello gcc Developers,

  I'm the CTO of Coverity, Inc., a company that does static source code 
analysis to look for defects in code. You may have heard of us or of our 
technology from its days at Stanford (the "Stanford Checker"). The 
reason I'm writing is because we have set up a framework internally to 
continually scan open source projects and provide the results of our 
analysis back to the developers of those projects. gcc is one of the 32 
projects currently scanned at:


http://scan.coverity.com

  My belief is that we (Coverity) must reach out to the developers of 
these packages (you) in order to make progress in actually fixing the 
defects that we happen to find, so this is my first step in that 
mission. Of course, I think Coverity technology is great, but I want to 
hear what you think and that's why I worked with folks at Coverity to 
put this infrastructure in place. The process is simple -- it checks out 
your code each night from your repository and scans it so you can always 
see the latest results.


  Right now, we're guarding access to the actual defects that we report 
for a couple of reasons: (1) We think that you, as developers of gcc, 
should have the chance to look at the defects we find to patch them 
before random other folks get to see what we found and (2) From a 
support perspective, we want to make sure that we have the appropriate 
time to engage with those who want to use the results to fix the code. 
Because of this second point, I'd ask that if you are interested in 
really digging into the results a bit further for your project, please 
have a couple of core maintainers (or group nominated individuals) reach 
out to me to request access. As this is a new process for us and still 
involves a small number of packages, I want to make sure that I 
personally can be involved with the activity that is generated from this 
effort.


  So I'm basically asking for people who want to play around with some 
cool new technology to help make source code better. If this interests 
you, please feel free to reach out to me directly. And of course, if 
there are other packages you care about that aren't currently on the 
list, I want to know about those too.


  If this is the wrong list, my sincerest apologies and please let me 
know where would be a more appropriate forum for this type of message.


Many thanks for reading this far...

-ben

 Ben Chelf
 Chief Technology Officer
 Coverity, Inc.

Re: Coverity Open Source Defect Scan of gcc

[Jim Blandy]

On 3/5/06, Ben Chelf <[EMAIL PROTECTED]> wrote:
>Right now, we're guarding access to the actual defects that we report
> for a couple of reasons: (1) We think that you, as developers of gcc,
> should have the chance to look at the defects we find to patch them
> before random other folks get to see what we found and (2) From a
> support perspective, we want to make sure that we have the appropriate
> time to engage with those who want to use the results to fix the code.

I think it's great that you're contributing the results of your
analysis to the GCC project.  Is this part of the work sponsored by
the U.S. Department of Homeland Security, described in
?

Re: when does Optimization happen....

[Ben Elliston]

> I understand that gcc -On happens before generating assembly code (.s), is 
> it correct?

Yes.

> But some optimization, such as inlining, may require cross
> compilation-unit (i.e, cross file) information.  It seems that these
> kind of optization is better to be handled at link time (thus, cross
> compilation units info is available).

Yes, you're right; and this is a current subject of discussion for the
way forward for GCC.  If you check the gcc@ mailing list archives
since December or so, you can see the discussion about "LTO" (link
time optimisation).

Ben

undefined BITS_PER_UNIT

[Rogelio Serrano]

When building gcc-4.1.0 with uclibc im getting and undefined
BITS_PER_UNIT error when building libgcc at the muldi3.

Where should this be defined? I added this definition in tm.h just to
be able to finish the build.

--
www.smsglobal.net SMS Global Ltd Short Message Service For Seafarers