I would have expected this to be undefined ...
So the static_assert could work or not.

>but it is not nullptr.

Or is it just undefined so it could be considered a nullptr ...

I think according to https://eel.is/c++draft/basic.stc#general-4 the function shall return an "invalid pointer valued". And nullptr is not considered such.

And if one modifies the function slightly (see auto p appear):

constexpr auto g() {
    int i = 0;
    auto p = &i;
    return p;
};

Then static_assert passes: https://gcc.godbolt.org/z/5shcxfcxG

(In reply to Andrew Pinski from comment #1)
> I would have expected this to be undefined ...
> So the static_assert could work or not.

If this were undefined (not true IIUC), static_assert would be required not to work because the condition expression is not a constant expression ([expr.const]/5.8).

We should keep in mind that all kinds of core UB that may occur within (tentative) constant evaluation (except for violation of [[assume]], currently) are not totally undefined, since they must cause constant evaluation failure. CWG issue should be submitted if such detection is unimplementable.

IIUC Nathaniel's patch at https://gcc.gnu.org/pipermail/gcc-patches/2023-July/623377.html will fix this.

The trunk branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:b8266af71c19a0bd7db4d08c8d2ee3c33214508c

commit r14-2772-gb8266af71c19a0bd7db4d08c8d2ee3c33214508c
Author: Nathaniel Shead <nathanieloshead@gmail.com>
Date:   Sun Jul 23 01:14:37 2023 +1000

    c++: Prevent dangling pointers from becoming nullptr in constexpr [PR110619]
    
    Currently, when typeck discovers that a return statement will refer to a
    local variable it rewrites to return a null pointer. This causes the
    error messages for using the return value in a constant expression to be
    unhelpful, especially for reference return values, and is also a visible
    change to otherwise valid code (as in the linked PR).
    
    The transformation is nonetheless important, however, both as a safety
    guard against attackers being able to gain a handle to other data on the
    stack, and to prevent duplicate warnings from later null-dereference
    warning passes.
    
    As such, this patch just delays the transformation until cp_genericize,
    after constexpr function definitions have been generated.
    
            PR c++/110619
    
    gcc/cp/ChangeLog:
    
            * cp-gimplify.cc (cp_genericize_r): Transform RETURN_EXPRs to
            not return dangling pointers.
            * cp-tree.h (RETURN_EXPR_LOCAL_ADDR_P): New flag.
            (check_return_expr): Add a new parameter.
            * semantics.cc (finish_return_stmt): Set flag on RETURN_EXPR
            when referring to dangling pointer.
            * typeck.cc (check_return_expr): Disable transformation of
            dangling pointers, instead pass this information to caller.
    
    gcc/testsuite/ChangeLog:
    
            * g++.dg/cpp1y/constexpr-110619.C: New test.
    
    Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>

(In reply to Andrew Pinski from comment #2)
> >but it is not nullptr.
> 
> Or is it just undefined so it could be considered a nullptr ...


Implementation-defined behaviour, according to answers on https://stackoverflow.com/questions/76843246/why-does-the-address-of-an-out-of-scope-variable-equal-zero-with-constexpr


https://eel.is/c++draft/basic.compound#def:value,invalid_pointer

https://eel.is/c++draft/basic.stc.general#4

>  Indirection through an invalid pointer value and passing an invalid pointer value to a deallocation function have undefined behavior.
> **Any other use of an invalid pointer value has implementation-defined behavior.**

So this wasn't a bug, but the new behaviour is also allowed.

This commit could be reverted or kept, depending on maintainability and/or quality-of-life for users of GCC.  Having it pick the other implementation-defined behaviour from clang (GCC's previous behaviour) is maybe a *good* thing, to help programmers catch dependence on an invalid pointer being either null or non-null if they try their code with both compilers.

Please note that GCC 13 also accepts invalid program (because dangling pointers were converted in nullptr):

constexpr auto f(int a) {
    return &a;
}

constexpr auto g(int b) {
    return &b;
}

static_assert(f(1) <= g(2));

This program must be rejected because of relational comparison of unrelated pointers as Clang and MSVC do, online demo: https://gcc.godbolt.org/z/q5z3Gvehe
And your patch fixes it as well, thanks.

(In reply to Fedor Chelnokov from comment #8)
> This program must be rejected because of relational comparison of unrelated
> pointers

I disagree. If GCC were to define the behaviour of returning invalid pointers during constant evaluation as converting them to null pointers, then those wouldn't be unrelated pointers. They'd be null pointers. And the comparison would be well defined.

But I don't think that conversion was ever intended as the defined behaviour, just an unintended consequence. If it was intended, it should have been documented at https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Implementation.html

The fact that we _don't_ do any such conversion should also be documented there, of course. We should say that other uses of invalid pointers do not modify the pointer values, so copying them preserves the invalid value (without trapping, except on Itanium?) and pointer comparisons and pointer arithmetic are undefined because they don't point to an object.