On Mon, Apr 25, 2016 at 11:35:46AM -0600, Jeff Law wrote:
> No, we revert to the gcc-4.9 behavior WRT protected visibility and ensure
> that we're getting a proper diagnostic from the linker.
>
> That direction is consistent with the intent of protected visibility, fixes
> the problem with preempt
On 04/19/2016 02:20 AM, Richard Biener wrote:
On Tue, Apr 19, 2016 at 7:08 AM, Alan Modra wrote:
On Mon, Apr 18, 2016 at 07:59:50AM -0700, H.J. Lu wrote:
On Mon, Apr 18, 2016 at 7:49 AM, Alan Modra wrote:
On Mon, Apr 18, 2016 at 11:01:48AM +0200, Richard Biener wrote:
To summarize: there is
On Mon, Apr 25, 2016 at 10:24 AM, Jeff Law wrote:
> On 04/18/2016 11:55 AM, Cary Coutant wrote:
That is why protected visibility is such a mess.
>>>
>>>
>>> Not mess, but it comes with certain limitations. And that's okay. It's
>>> intended as an optimization, and it should do that opt
On 04/18/2016 11:55 AM, Cary Coutant wrote:
That is why protected visibility is such a mess.
Not mess, but it comes with certain limitations. And that's okay. It's
intended as an optimization, and it should do that optimization if
requested, and error out if it can't be done for whatever reas
On 04/21/2016 01:53 PM, Michael Meissner wrote:
As I start to allow integer modes into vector registers, I need to revisit
MODES_TIEABLE_P. I'm wondering if MODES_TIEABLE_P is transitive?
I don't recall a need for it to be transitive. The only really special
thing I remember about MODES_TIEABLE
> 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
> 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 almos
> 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
> 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 REFEREN
> 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 wha
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 represent
> 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. Possib
On Sat, Apr 23, 2016 at 1:23 PM, Eric Botcazou 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
13 matches
Mail list logo
