On September 26, 2014 5:14:24 PM CEST, Bernd Schmidt
wrote:
>On 09/26/2014 02:42 PM, Richard Biener wrote:
>> On Fri, Sep 26, 2014 at 2:28 PM, Bernd Schmidt
> wrote:
>>> On 09/26/2014 02:26 PM, Richard Biener wrote:
On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt
>
wrote:
>
On 09/26/2014 02:42 PM, Richard Biener wrote:
On Fri, Sep 26, 2014 at 2:28 PM, Bernd Schmidt wrote:
On 09/26/2014 02:26 PM, Richard Biener wrote:
On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt
wrote:
On 09/26/2014 02:05 PM, Richard Biener wrote:
If currently address-space support matche
On Fri, Sep 26, 2014 at 2:28 PM, Bernd Schmidt wrote:
> On 09/26/2014 02:26 PM, Richard Biener wrote:
>>
>> On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt
>> wrote:
>>>
>>> On 09/26/2014 02:05 PM, Richard Biener wrote:
If currently address-space support matches up with the C fronte
On 09/26/2014 02:26 PM, Richard Biener wrote:
On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt wrote:
On 09/26/2014 02:05 PM, Richard Biener wrote:
If currently address-space support matches up with the C frontend
and the C standard then the middle-end has to cope with that.
In this case, cope
On Fri, Sep 26, 2014 at 2:14 PM, Bernd Schmidt wrote:
> On 09/26/2014 02:05 PM, Richard Biener wrote:
>>
>> If currently address-space support matches up with the C frontend
>> and the C standard then the middle-end has to cope with that.
>> In this case, cope with array element types not having a
On 09/26/2014 02:05 PM, Richard Biener wrote:
If currently address-space support matches up with the C frontend
and the C standard then the middle-end has to cope with that.
In this case, cope with array element types not having address-space
qualifiers.
That's the opposite of what happens. The
On Fri, Sep 26, 2014 at 2:00 PM, Bernd Schmidt wrote:
> On 09/16/2014 02:59 PM, Richard Biener wrote:
>>
>> On Tue, Sep 16, 2014 at 1:24 PM, Bernd Schmidt
>> wrote:
>>>
>>> Ok, so testing seems to show that nothing breaks with the ARRAY_TYPE
>>> special
>>> case removed. However, I remembered ano
On 09/16/2014 02:59 PM, Richard Biener wrote:
On Tue, Sep 16, 2014 at 1:24 PM, Bernd Schmidt wrote:
Ok, so testing seems to show that nothing breaks with the ARRAY_TYPE special
case removed. However, I remembered another reason to do this, and it's for
consistency with how address spaces are re
On Wed, 17 Sep 2014, Bernd Schmidt wrote:
> On 09/16/2014 11:18 PM, Joseph S. Myers wrote:
>
> > (That TYPE_MAIN_VARIANT maps an array of qualified type to an array of
> > corresponding unqualified type necessitates lots of special cases in the
> > front end to avoid applying TYPE_MAIN_VARIANT to
On 09/16/2014 11:18 PM, Joseph S. Myers wrote:
(That TYPE_MAIN_VARIANT maps an array of qualified type to an array of
corresponding unqualified type necessitates lots of special cases in the
front end to avoid applying TYPE_MAIN_VARIANT to array types, since in C
terms array types are always unq
On Tue, 16 Sep 2014, Bernd Schmidt wrote:
> > It's not an implementation detail, it's how TR 18037 defines them, and
> > thus how the C front end should represent them in order to follow the
> > requirements of TR 18037.
>
> My position is that standards do not mandate how our internal data struc
On 09/16/2014 10:56 PM, Joseph S. Myers wrote:
On Tue, 16 Sep 2014, Richard Biener wrote:
Hmm. How is it with other compositive types like vectors and complex?
It's bad that the middle-end needs to follow a specific frontends need.
Why's the representation tied so closely together?
Complex t
On Tue, 16 Sep 2014, Richard Biener wrote:
> Hmm. How is it with other compositive types like vectors and complex?
> It's bad that the middle-end needs to follow a specific frontends need.
> Why's the representation tied so closely together?
Complex types aren't derived types in C terms; they do
On Tue, Sep 16, 2014 at 1:24 PM, Bernd Schmidt wrote:
> On 09/12/2014 01:48 PM, Richard Biener wrote:
>>
>> On Fri, Sep 12, 2014 at 1:15 PM, Bernd Schmidt
>> wrote:
>>>
>>> On 09/11/2014 01:29 PM, Richard Biener wrote:
+ if (TREE_CODE (type) == ARRAY_TYPE)
+TREE_TYPE (typ
On 09/12/2014 01:48 PM, Richard Biener wrote:
On Fri, Sep 12, 2014 at 1:15 PM, Bernd Schmidt wrote:
On 09/11/2014 01:29 PM, Richard Biener wrote:
+ if (TREE_CODE (type) == ARRAY_TYPE)
+TREE_TYPE (type) = apply_as_to_type (TREE_TYPE (type), as);
why is this necessary for ARRAY_TYPE but n
On Fri, Sep 12, 2014 at 1:56 PM, Bernd Schmidt wrote:
> On 09/12/2014 01:48 PM, Richard Biener wrote:
>>>
>>> Still testing whether I actually strictly need it for ARRAY_TYPE nowadays
>>> (these patches are really old...). However, the TYPE_FIELDS of a
>>> RECORD_TYPE
>>> seem to be mostly ignored
On 09/12/2014 01:48 PM, Richard Biener wrote:
Still testing whether I actually strictly need it for ARRAY_TYPE nowadays
(these patches are really old...). However, the TYPE_FIELDS of a RECORD_TYPE
seem to be mostly ignored once the frontends are done, but it's very easy
for other parts of the com
On Fri, Sep 12, 2014 at 1:15 PM, Bernd Schmidt wrote:
> On 09/11/2014 01:29 PM, Richard Biener wrote:
>>
>> + if (TREE_CODE (type) == ARRAY_TYPE)
>> +TREE_TYPE (type) = apply_as_to_type (TREE_TYPE (type), as);
>>
>> why is this necessary for ARRAY_TYPE but not for sth like
>> a RECORD_TYPE or
On 09/11/2014 01:29 PM, Richard Biener wrote:
+ if (TREE_CODE (type) == ARRAY_TYPE)
+TREE_TYPE (type) = apply_as_to_type (TREE_TYPE (type), as);
why is this necessary for ARRAY_TYPE but not for sth like
a RECORD_TYPE or a POINTER_TYPE?
Still testing whether I actually strictly need it for
On Thu, Sep 11, 2014 at 12:11 PM, Bernd Schmidt wrote:
> I'm getting ready to submit the ptx port and the various changes that are
> necessary for it. To start with, here are some patches to deal with address
> space issues.
>
> ptx has the concept of an implicit address space: everything (objects
20 matches
Mail list logo
