This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimizations on long long multiply/divide on PowerPC32 don'twork



On Mon, 10 Dec 2001, Richard Henderson wrote:

> On Sun, Dec 09, 2001 at 10:58:14PM -0800, Linus Torvalds wrote:
> > I'm sorry you feel that way, but what the gcc team has done to libgcc
> > has only made me _more_ convinced that not linking against that
> > steenking heap of *** is a really good idea..
>
> Ok, I'll bite -- what have we done to libgcc?

These days libgcc has a _lot_ of "non-architecture" stuff.

It used to be that libgcc only had the arithmetic etc extensions, for
things purely like "instruction extensions". Fair enough.

But do a "nm libgcc.a" today, and you get literally _pages_ of output of
things that have absolutely _zero_ to do with machine descriptions.

It has weak symbols for stuff like the pthreads stuff.

There is no way any of that must ever make it into the kernel even by
mistake. Having the compiler emit that crap and silently link against it
would be a _major_ mistake in my opinion.

And don't tell me it doesn't happen. The exception code DID in fact
happen, and if it weren't for the lack of libgcc in the kernel, I would
never have been told by people who started using snapshot compilers.

> > The fact that gcc cannot do a 64-bit divide by a constant is a gcc
> > deficiency.  But it is NOT cause for including crap in the kernel.
>
> Hogwash.  Look at the example again.  Signed division is not merely
> a shift.  It's more like

[ deleted ]

That's fine, but that _still_ supports my point 100%.

Read my email again. Read the part about why we do not want to have the
slow crap routines, when most likely the user really _wanted_ a unsigned
shift in the first place.

		Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]