https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116016
--- Comment #15 from Siddhesh Poyarekar <siddhesh at gcc dot gnu.org> --- (In reply to qinzhao from comment #14) > If we go with the category B (as I mentioned in Comment #9), define the new > builtin as a regular builtin, > Then, arbitrary pointer for the 1st parameter is fine. > If we go with the category A, i.e, define the new builtin as a C language > extension as a key word, then I think that > The 1st parameter is better to be a FAM_exp. > > I think for our purpose of using this new builtin, defining it as a > RID_BUITLIN should be enough. > > However, I am open to define it as a regular builtin and implement it in the > middle-end. If there are no actual problems with associating a size expression with an object then I'd lean towards making it arbitrary. Either way though, one thing the compiler would have to guard against (and document) is the possibility of an object changing after this association is made. This could either be due to reallocation or the pointer pointing to a different object. The compiler can probably make out if this happens within the function where this builtin is called, but if the object gets modified in a different function which the compiler cannot see into, or in a different thread in parallel, then it will be the responsibility of the user to make sure that the modification gets reflected in the size expression somehow. Also, I reckon this expression will have to become a barrier to code reordering, similar to the .ACCESS_WITH_SIZE internal builtin.
