On 06/15/2010 11:02 AM, Paulo J. Matos wrote:
Just noticed the following also in optabs.c:
/* We can't do it with an insn, so use a library call. But first ensure
that the mode of TO is at least as wide as SImode, since those are the
only library calls we know about. */
if (
Hi,
On Tue, 15 Jun 2010, Paulo J. Matos wrote:
> >> 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
>
On Tue, Jun 15, 2010 at 1:00 PM, Joern Rennecke wrote:
> Quoting "Paulo J. Matos" :
>
>> On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke
>> 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
Quoting "Paulo J. Matos" :
On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke 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 oper
On Tue, Jun 15, 2010 at 11:46 AM, Joern Rennecke 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. t
On Tue, Jun 15, 2010 at 10:42 AM, Joseph S. Myers
wrote:
> On Tue, 15 Jun 2010, Paulo J. Matos wrote:
>
> For targets with 8-bit bytes and 32-bit registers (and without hardware
> floating point), there is probably no point in having most conversion
> functions to/from QImode or HImode separate fr
Quoting "Joseph S. Myers" :
For targets with 8-bit bytes and 32-bit registers (and without hardware
floating point), there is probably no point in having most conversion
functions to/from QImode or HImode separate from those to/from SImode, as
they likely wouldn't be any more efficient so would
On Tue, 15 Jun 2010, Paulo J. Matos wrote:
> This comment provides some insight on to why gcc keeps converting to
> SImode. However, I think (and it is at least applicable to my case)
> that it should convert to QImode and if there are no libraries, tell
> the implementor of the backend to provid
On Tue, Jun 15, 2010 at 9:17 AM, Paulo J. Matos wrote:
> On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
> wrote:
>>
>> Every hardcoded reference to a mode other than QImode in the
>> target-independent compiler is suspicious and needs investigating if you
>> are doing such a port. In this case
On Tue, Jun 15, 2010 at 9:17 AM, Paulo J. Matos wrote:
> On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
> wrote:
>>
>> Every hardcoded reference to a mode other than QImode in the
>> target-independent compiler is suspicious and needs investigating if you
>> are doing such a port. In this case
On Mon, Jun 14, 2010 at 7:01 PM, Ian Lance Taylor wrote:
> "Paulo J. Matos" writes:
>
>> In gcc4.3.4, for my architecture: 16 BITS_PER_UNIT, 1 UNIT_PER_WORD,
>> with INT_TYPE_SIZE = 16 and FLOAT_TYPE_SIZE = 32, then an unsigned int
>> is QImode and a float is HFmode.
>>
>> However with:
>> float
On Mon, Jun 14, 2010 at 8:56 PM, Joseph S. Myers
wrote:
>
> Every hardcoded reference to a mode other than QImode in the
> target-independent compiler is suspicious and needs investigating if you
> are doing such a port. In this case, the SImode references in
> expand_float are likely the problem
On Mon, 14 Jun 2010, Paulo J. Matos wrote:
> Hello,
>
> In gcc4.3.4, for my architecture: 16 BITS_PER_UNIT, 1 UNIT_PER_WORD,
> with INT_TYPE_SIZE = 16 and FLOAT_TYPE_SIZE = 32, then an unsigned int
> is QImode and a float is HFmode.
To attempt such a port, being an expert in GCC internals is a g
"Paulo J. Matos" writes:
> In gcc4.3.4, for my architecture: 16 BITS_PER_UNIT, 1 UNIT_PER_WORD,
> with INT_TYPE_SIZE = 16 and FLOAT_TYPE_SIZE = 32, then an unsigned int
> is QImode and a float is HFmode.
>
> However with:
> float uitof(unsigned int x) { return x; }
>
> I get a call to the functio
Hello,
In gcc4.3.4, for my architecture: 16 BITS_PER_UNIT, 1 UNIT_PER_WORD,
with INT_TYPE_SIZE = 16 and FLOAT_TYPE_SIZE = 32, then an unsigned int
is QImode and a float is HFmode.
However with:
float uitof(unsigned int x) { return x; }
I get a call to the function __floatunsihf. Shouldn't this b
15 matches
Mail list logo