Re: Recent libgcc2 changes broken

[Jakub Jelinek <jakub at redhat dot com>]

On Fri, Jan 07, 2000 at 12:59:11PM -0700, Jeffrey A Law wrote:
> 
> I don't see how all the recent changes in libgcc2 are supposed to work, there's
> something badly broken here.
> 
> Previously when we built libgcc2 we would define something like
> L_fixunssfsi which would cause the _fixunssfsi routine to be built.
> 
> With your new code, the modes used by libgcc2 change based on the word
> size of the target.  For example on a 16bit target (mn102) defining
> L_fixunssfsi will actually result in a routine called fixunssfhi because
> the word size is 16 bits.

First of all, I'd mention only the last patch is relevant to this I believe
(will have to check to be sure).

Do you see something fundamentally broken with it apart from the
inconsistant L_* naming? Why had been c4x port forced to redefine SI/DI, so
that those modes are actually QI/HI and the routines continued to have names
which did not reflect what they are actually doing and what arguments they
take. This patch was an answer to Michael Hayes' complains about the previous
patches which broke c4x exactly because -DDI=HI -DSI=QI no longer worked
(one would have to redefine some other things as well).
The whole longlong.h is really about extending arithmetic support to twice
what can the architecture handle without the library.
What is e.g. fixunssfdi on mn10200 needed for when even long long is SImode?
Current libgcc2.c would build fixunssfhi and fixunssfsi.
Actually, if you think it makes sense to build di routines on 16bitters,
then I can just kill the UNITS_PER_WORD > 1 conditional and use what is in
UNITS_PER_WORD > 2 now for all UNITS_PER_WORD > 1.
From Michael's mails I understood he'd want libgcc2.c to provide addhi3 and
the like functions for him on dsps.
The L_* naming can be fixed easily to make it word-size neutral.

> 
> That is badly wrong, in fact, the whole notion of changing the names of
> the routines that get built based on the word size is horribly wrong.  The
> notion that we have to have IN_LIBGCC2 to defining TARGET_BLAH macros to
> constants is badly wrong too.

That was an alternative to introduce new LIBGCC2_ defines,
LIBGCC2_UNITS_PER_WORD, LIBGCC2_BITS_PER_UNIT, which would have to be
defined on h8300, mips, rs6000 and sparc and was inspired by what sparc port
already had been doing for quite some time.
If you think introducing those new defines is cleaner, then I can change
that, but would have to find out which further macros would have to be
introduced so that it could be removed from the sparc headers as well.

Cheers,
    Jakub
___________________________________________________________________
Jakub Jelinek | jakub@redhat.com | http://sunsite.mff.cuni.cz/~jj
Linux version 2.3.36 on a sparc64 machine (1343.49 BogoMips)
___________________________________________________________________