Re: internal_reference_types

2016-04-25 Thread Richard Kenner
> Yes, the address space stuff is posterior, but the Pmode thing is verbatim.

Doesn't ring a bell.  Sorry.  I don't even remember what the other
option would be other than Pmode.

> REFERENCE_TYPEs and POINTER_TYPEs are (should be) treated almost equally in 
> the compiler, the difference matters only for the debug info.  We use the 
> former much more now than we used to in gigi, because of the debug info.

Right.  The transition to using REFERENCE_TYPEs more started back in my time.


Re: internal_reference_types

2016-04-25 Thread Eric Botcazou
> Hmm... what else would REFERENCE_TYPEs be?  I remember none of this and
> it's clear that it was later changed because of the reference to address
> spaces.

Yes, the address space stuff is posterior, but the Pmode thing is verbatim.
REFERENCE_TYPEs and POINTER_TYPEs are (should be) treated almost equally in 
the compiler, the difference matters only for the debug info.  We use the 
former much more now than we used to in gigi, because of the debug info.

-- 
Eric Botcazou


Re: internal_reference_types

2016-04-25 Thread Richard Kenner
> The commit from 2001 has your name on it.  It's called from gigi:
> 
>   /* Show that REFERENCE_TYPEs are internal and should be Pmode.  */
>   internal_reference_types ();

Hmm... what else would REFERENCE_TYPEs be?  I remember none of this and
it's clear that it was later changed because of the reference to address
spaces.


Re: internal_reference_types

2016-04-25 Thread Eric Botcazou
> I don't think I added that.  In fact, I'm not sure what the term
> "address spaces' address_mode" means: I think that was added after I
> stopped working on GCC.  So I don't know either.  Is it ever called?

The commit from 2001 has your name on it.  It's called from gigi:

  /* Show that REFERENCE_TYPEs are internal and should be Pmode.  */
  internal_reference_types ();

-- 
Eric Botcazou


Re: internal_reference_types

2016-04-25 Thread Richard Kenner
> Only Richard K. might remember the details.  Possibly for
> IA-64/HP-UX -milp32.  In any case, having a different representation
> for pointers and references is a recipe for annoying issues like
> this, so removing the kludge is OK with me.

I don't think I added that.  In fact, I'm not sure what the term
"address spaces' address_mode" means: I think that was added after I
stopped working on GCC.  So I don't know either.  Is it ever called?


Re: internal_reference_types

2016-04-25 Thread Richard Biener
On Mon, Apr 25, 2016 at 12:19 PM, Eric Botcazou  wrote:
>> What (Ada!) targets would it make a difference on?  As it affects TYPE_SIZE
>> it also affects layout (obviously), so I wonder how this can be an
>> optimization (I assume it was intended to be one - likely for Adas fat
>> pointer representation?)
>
> Only Richard K. might remember the details.  Possibly for IA-64/HP-UX -milp32.
> In any case, having a different representation for pointers and references is
> a recipe for annoying issues like this, so removing the kludge is OK with me.

With me as well - patch pre-approved on the middle-end side.

Richard.

> --
> Eric Botcazou


Re: internal_reference_types

2016-04-25 Thread Eric Botcazou
> What (Ada!) targets would it make a difference on?  As it affects TYPE_SIZE
> it also affects layout (obviously), so I wonder how this can be an
> optimization (I assume it was intended to be one - likely for Adas fat
> pointer representation?)

Only Richard K. might remember the details.  Possibly for IA-64/HP-UX -milp32.
In any case, having a different representation for pointers and references is 
a recipe for annoying issues like this, so removing the kludge is OK with me.

-- 
Eric Botcazou


Re: internal_reference_types

2016-04-25 Thread Richard Biener
On Sat, Apr 23, 2016 at 1:23 PM, Eric Botcazou <ebotca...@adacore.com> wrote:
>> The function internal_reference_types appears to have been introduced
>> exclusively for the Ada frontend.  It is responsible for PR70759 (ada
>> rts doesn't build with -mabi=ilp32).  What purpose does it serve and
>> what breaks when it is removed?  The history doesn't give any hints.
>
> Not clear to me either and the premise is probably wrong for Ada these days.

What (Ada!) targets would it make a difference on?  As it affects TYPE_SIZE
it also affects layout (obviously), so I wonder how this can be an optimization
(I assume it was intended to be one - likely for Adas fat pointer
representation?)

So might be a target with pointer mode bigger than Pmode (so where Pmode is
a partial int mode?)

Richard.

> --
> Eric Botcazou


Re: internal_reference_types

2016-04-23 Thread Eric Botcazou
> The function internal_reference_types appears to have been introduced
> exclusively for the Ada frontend.  It is responsible for PR70759 (ada
> rts doesn't build with -mabi=ilp32).  What purpose does it serve and
> what breaks when it is removed?  The history doesn't give any hints.

Not clear to me either and the premise is probably wrong for Ada these days.

-- 
Eric Botcazou


internal_reference_types

2016-04-22 Thread Andreas Schwab
The function internal_reference_types appears to have been introduced
exclusively for the Ada frontend.  It is responsible for PR70759 (ada
rts doesn't build with -mabi=ilp32).  What purpose does it serve and
what breaks when it is removed?  The history doesn't give any hints.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."