Re: GCC 4.3.4 is casting my QImode vars to SImode for libcall

["Paulo J. Matos" <pocmatos at gmail dot com>]

On Tue, Jun 15, 2010 at 1:00 PM, Joern Rennecke <amylaar@spamcop.net> wrote:
> Quoting "Paulo J. Matos" <pocmatos@gmail.com>:
>
>> On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke <amylaar@spamcop.net>
>> wrote:
>>>
>>> I think it is also a reflection of an 'all the world is (at least) 32
>>> bit'
>>> attitude - in part supported by the GNU coding standard as it was then
>>> aimed at making an easily maintainable workstation / server operating
>>> system.
>>> I.e. the C "int" type was assumed to be 32 bit. ÂAnd gcc stood for
>>> 'GNU C compiler' - and C has type promotion rules that mean you don't
>>> need
>>> to convert floating point from/to integer types narrower than int.
>>>
>>
>> I can't understand those statements in the sense that GCC was meant to
>> be a generic compiler framework therefore having code tying GCC to
>> specific archs should be specific in the manual or elsewhere.
>
> I was merely trying to give some historical context to help interpret
> what that SImode check should really be.
>

Yes, I understand, thanks. I am sorry if my reply seemed a bit
confrontational. That was not the intent.

>> Is GCC slowly losing support
>> for certain archs or it is still striving to be as generic as
>> possible?
>
> GCC looses and gains support for architectures depending on the availability
> of competent volunteer maintainers for these architectures.
> Of course, 'volunteer' in this context can also mean that a company
> volunteers to employ / contract with a developer to do this work.
>

But while the backends might vary as much as they like, the core gcc
code such as optabs.c should be as generic as possible, right?

-- 
PMatos