Re: internal_reference_types
> 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
> 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
> 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
> 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
> 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
On Mon, Apr 25, 2016 at 12:19 PM, Eric Botcazouwrote: >> 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
> 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
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
> 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
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."