This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFC] Init sizetypes based on target defs


> This initializes sizetypes correctly from the start, using target
> definitions available.  All Frontends initialize sizetypes from
> size_type_node for which there is a target macro SIZE_TYPE which
> tells what type to use for this (C runtime ABI) type.

And this is a prerequisite if you want to do LTO in the language; otherwise, 
LTO doesn't work at all, for example for Ada on the 4.5 branch.

> so the FE itself doesn't care and POINTER_SIZE for almost all targets
> yields the same result as following the SIZE_TYPE advice.  Ada has
> its own idea and thinks it can choose size_t freely,

Yes, like for boolean_type_node, you can set size_type_node to whatever you 
want as long as you don't do LTO.  At least it must be unsigned now.

> hmm, yes.  Again practically for most targets size_t will be following
> its SIZE_TYPE advice, but surely not for all.  OTOH while the above
> clearly doesn't look "accidential", it certainly looks wrong.  If
> not for sizetype then at least for size_type_node.  The comment hints
> that the patch at most will no longer "get better code", but if
> Pmode gets better code when used for sizetype(!) then we should do
> so unconditionally and could get rid of the size_t reverse-engineering
> in initialize_sizetypes completely (m32c might disagree here).

The thing is, I don't think you can have different types for size_type_node and 
the *sizetype series.  So, while for the C family of language, you are forced 
to use SIZE_TYPE for both because of size_t, you still need to have the same 
type for the other languages.

> Now, any objections?  (Patch to be adjusted to really remove
> all set_sizetype calls)

Fine with me at least.  When I was changing the signedness of sizetype in Ada, 
I hesitated to remove the Pmode vs ptr_mode kludge and eventually erred on the 
side of conservatism.  But it clearly needs to go and now seems a good time.

-- 
Eric Botcazou


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]