On Sat, Jul 2, 2011 at 12:59 AM, Bernd Schmidt wrote:
> On 07/02/11 00:11, Joseph S. Myers wrote:
>> On Fri, 1 Jul 2011, Bernd Schmidt wrote:
>>
* The global tree nodes for various modes are suspicious. Why are they
needed at all?
>>>
>>> Do you mean only the PImode ones or also intQI_t
On Sat, Jul 2, 2011 at 12:11 AM, Joseph S. Myers
wrote:
> On Fri, 1 Jul 2011, Bernd Schmidt wrote:
>
>> > * The global tree nodes for various modes are suspicious. Why are they
>> > needed at all?
>>
>> Do you mean only the PImode ones or also intQI_type_node etc.? These are
>> used to pick a sui
On 07/02/11 00:11, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Bernd Schmidt wrote:
>
>>> * The global tree nodes for various modes are suspicious. Why are they
>>> needed at all?
>>
>> Do you mean only the PImode ones or also intQI_type_node etc.? These are
>> used to pick a suitable type in c
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> On 07/01/11 23:18, Bernd Schmidt wrote:
> >> What is the function of having both PARTIAL_INT_MODE and
> >> FRACTIONAL_INT_MODE?
> >
> > Not having to change all the targets using PARTIAL_INT_MODE immediately
> > to use the better mechanism.
>
> Also, c
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> > * The global tree nodes for various modes are suspicious. Why are they
> > needed at all?
>
> Do you mean only the PImode ones or also intQI_type_node etc.? These are
> used to pick a suitable type in c_common_type_for_size.
All of them.
> > * The
On 07/01/11 23:18, Bernd Schmidt wrote:
>> What is the function of having both PARTIAL_INT_MODE and
>> FRACTIONAL_INT_MODE?
>
> Not having to change all the targets using PARTIAL_INT_MODE immediately
> to use the better mechanism.
Also, come to think of it, preventing the rest of the compiler fr
On 07/01/11 22:36, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Bernd Schmidt wrote:
>> The idea here is that there is more than one target that supports 40 bit
>> operations, so why shouldn't we have support for it in
>> target-independent code and libgcc? It differs from QI/HI/SImode etc. in
>> t
One more general point:
There are further issues around what we might call "extended types that
behave much like integer and floating-point types", especially for C++;
see my comment in PR 43622, and the references therein. How to fix these
(again, while avoiding hardcoding references to such
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> On 07/01/11 21:49, Joseph S. Myers wrote:
> > On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> >
> >> * Should we add an __int40_t keyword, or just do a pushdecl for it?
> >>The patch currently does the latter to match __int128_t, but
> >>decimal floa
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> On 07/01/11 22:04, Joseph S. Myers wrote:
> > I should add: make the type, the new mode, the testcases etc. entirely
> > target-specific; target-independent GCC should not need to know or care
> > about the specifics of this type. It's bad enough targe
On 07/01/11 22:18, Paul Koning wrote:
>> PDImode is so far always defined as MODE_PARTIAL_INT which is handled
>> quite differently (i.e. by not handling it very much at all). IMO it
>> would be a bad idea to overload the name.
>
> Would it make sense to fix the "not much at all" problem?
Ideally
On 07/01/11 21:49, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Bernd Schmidt wrote:
>
>> * Should we add an __int40_t keyword, or just do a pushdecl for it?
>>The patch currently does the latter to match __int128_t, but
>>decimal float and fixed-point support uses keywords. This may make
On Jul 1, 2011, at 4:14 PM, Bernd Schmidt wrote:
> On 07/01/11 22:04, Joseph S. Myers wrote:
>> I should add: make the type, the new mode, the testcases etc. entirely
>> target-specific; target-independent GCC should not need to know or care
>> about the specifics of this type. It's bad enough
On 07/01/11 22:04, Joseph S. Myers wrote:
> I should add: make the type, the new mode, the testcases etc. entirely
> target-specific; target-independent GCC should not need to know or care
> about the specifics of this type. It's bad enough target-independent GCC
> knowing about HImode, SImode,
I should add: make the type, the new mode, the testcases etc. entirely
target-specific; target-independent GCC should not need to know or care
about the specifics of this type. It's bad enough target-independent GCC
knowing about HImode, SImode, DImode and TImode outside default target
hook im
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> * Should we add an __int40_t keyword, or just do a pushdecl for it?
>The patch currently does the latter to match __int128_t, but
>decimal float and fixed-point support uses keywords. This may make
>a difference for (existing) code using "uns
16 matches
Mail list logo
