On Fri, May 22, 2015 at 5:00 AM, Jan Hubicka hubi...@ucw.cz wrote:
Now we have it spelled out 4 times ... makes sense to create a new
macro for it? (though I cannot think of a good name...
UNACCESSIBLE_TYPE_P ()?)
Yep, actually I already made that version of patch yesterday but then got
On Sun, May 24, 2015 at 5:49 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, May 22, 2015 at 5:00 AM, Jan Hubicka hubi...@ucw.cz wrote:
Now we have it spelled out 4 times ... makes sense to create a new
macro for it? (though I cannot think of a good name...
UNACCESSIBLE_TYPE_P ()?)
Yep,
On Thu, 21 May 2015, Jan Hubicka wrote:
Hi,
this is next part of the series. It disables canonical type calculation for
incomplete types with exception of arrays based on claim that we do not have
good notion of those.
I can botostrap this with additional checks in alias.c that canonical
Now we have it spelled out 4 times ... makes sense to create a new
macro for it? (though I cannot think of a good name...
UNACCESSIBLE_TYPE_P ()?)
Yep, actually I already made that version of patch yesterday but then got
hooked by beers. This is better version (also with more sensible
+ /* No need for canonical types of functions and methods; those are never
+ accessed as memory locations. */
+ if (TREE_CODE (t) == FUNCTION_TYPE || TREE_CODE (t) == METHOD_TYPE)
+return;
Just occured to me that it might make sense to remove the
FUNCTION/METHOD_TYPE case in
Hi,
this is next part of the series. It disables canonical type calculation for
incomplete types with exception of arrays based on claim that we do not have
good notion of those.
I can botostrap this with additional checks in alias.c that canonical types are
always present with LTO but I need
