[Bug c++/112414] Does gcc need __builtin_assume_separate_storage?

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112414

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
__builtin_assume_separate_storage

__builtin_assume_separate_storage is used to provide the optimizer with the
knowledge that its two arguments point to separately allocated objects.

Syntax:

__builtin_assume_separate_storage(const volatile void *, const volatile void *)

Example of Use:

int foo(int *x, int *y) {
    __builtin_assume_separate_storage(x, y);
    *x = 0;
    *y = 1;
    // The optimizer may optimize this to return 0 without reloading from *x.
    return *x;
}

Description:

The arguments to this function are assumed to point into separately allocated
storage (either different variable definitions or different dynamic storage
allocations). The optimizer may use this fact to aid in alias analysis. If the
arguments point into the same storage, the behavior is undefined. Note that the
definition of “storage” here refers to the outermost enclosing allocation of
any particular object (so for example, it’s never correct to call this function
passing the addresses of fields in the same struct, elements of the same array,
etc.).

Query for this feature with __has_builtin(__builtin_assume_separate_storage).


---

The given syntax makes it very unuseful given there's no data dependence
involved.  I assume it is supposed to work like

 typeof (x) __restrict xr = x;
 typeof (y) __restrict yr = y;
 *xr = 0;
 *yr = 1;

not sure why clang folks thought a new builtin is a great idea.  Even this
restrict form is more useful (but there's reasons we don't support that
either).

So no, RESOLVED BADFEATURE.