> This seems mostly plausible, though I don't see anything to ensure that > __intN does not exist at all if the size matches one of the standard C > types,
My thought here was that, since each __intN is specified by the target, they'd know to only do so if it doesn't match an existing (for that target) type. But what if it does? What if the standard types changed based on command line options, and the target wanted to offer an __intN as a "this will always work" alternative to standard types? I did code it such that standard types are preferred over __intN types in the searches. > or if the mode fails targetm.scalar_mode_supported_p. As I mentioned, I haven't added that part yet. My though there is to add a runtime flag to the int_n_trees[] array and have each loop over that data check the flag. I suppose I could check for the types being NULL but IIRC there are cases that only use the genmodes data and not the types. For aesthetic reasons I wanted to keep the flag separate. > (To move __int128 to this system, given that its availability will I put all the new code alongside the __int128 code, so the __int128 code can just be cut out after the new code is in place, but that's down the road a bit.
