> In general you need to analyze each such case individually to produce a > reasoned argument for what it should logically be doing. Given such > analyses, maybe then you can identify particular tables of types in > particular orders (for example) that should be set up to iterate through.
Ok, I'll do this next, except it's what I did first... and we still haven't decided how to handle some of those cases. I'll re-analyze. > Does the target with __int20 actually have __int128 (i.e. pass > targetm.scalar_mode_supported_p (TImode))? But you should indeed be able > to have an arbitrary number of such types. It doesn't support it, but it does *have* it. In that the compiler correcly parses the __int128 keyword and knows to tell you it isn't supported. So, it needs at least two keywords. Which implies "it needs two..." in other places. And it's reasonable to expect that *someone* will want int16, int32, etc types once a general solution is in place. > (d) I don't think the standard C types are particularly relevant to your > project. Should we be pulling the int128 support out of the integer_types[] list and put it in the global_trees[] (or some table) list? Because most of the int128 support is tied in with the standard C type handling, not the target-specific handling.
