On Thu, Feb 12, 2026 at 01:48:59PM +0900, Jason Merrill wrote:
> > --- gcc/cp/constexpr.cc.jj 2026-02-09 09:06:41.657345262 +0100
> > +++ gcc/cp/constexpr.cc 2026-02-10 13:09:30.059258053 +0100
> > @@ -42,6 +42,7 @@ along with GCC; see the file COPYING3.
> > #include "intl.h"
> > #include "toplev.h"
> > #include "contracts.h"
> > +#include "c-family/c-pragma.h"
>
> Is this still needed for this version?
It is new in this version, so that parse_in can be used when translating
the messages back from exec charset/UTF-8 to SOURCE_CHARSET.
If it is moved to semantics.cc through overload with constexpr_ctx, I guess
it will not be needed.
> > static bool verify_constant (tree, bool, bool *, bool *);
> > #define VERIFY_CONSTANT(X)
> > \
> > @@ -2314,6 +2315,295 @@ cxx_eval_cxa_builtin_fn (const constexpr
> > }
> > }
> > +/* Attempt to evaluate T which represents a call to
> > __builtin_constexpr_diag.
> > + The arguments should be an integer (0 for inform, 1 for warning, 2 for
> > + error) and 2 messages which are either a pointer to a STRING_CST or
> > + class with data () and size () member functions like string_view or
> > + u8string_view. */
>
> Please explain the significance of the two messages as well. And also the
> expected types.
Will do.
> Why is the tag string before the message string, since the tag is the one
> that's sometimes omitted?
Tag comes first because that is what P2758R5 says in its API, the builtin
attempts to match those (except that it has an extra first argument which
differentiates error/warning/print).
> > + /* Can't use cstr.extract because it evaluates the
> > + arguments in separate constexpr contexts. */
>
> Didn't I already suggest adding another overload that takes a constexpr_ctx?
> This is too much code to duplicate in a user.
Will do.
> > + constexpr void constexpr_print_str(string_view __msg) noexcept
> > + { return __builtin_constexpr_diag(0, "", __msg); }
> > // { dg-message "constexpr message: foo" }
>
> Hmm, it would be more useful if the messages were at the call site of this
> function rather than at the definition. I guess you can get that location
> from call_stack. But this can be a followup.
Well, it really depends on whether one uses the builtin directly (when
the thing is not standardized yet, perhaps Jonathan will not want to
add the standard APIs in libstdc++ just yet) or through wrappers like
that.
One option would be figure the location_t of caller vs. of caller's caller
through checking if the caller is std::constexpr_{print,warning,error}_str,
another would be to say or in magic constant (say 16) into the first
argument if it wants caller's caller location_t.
Jakub
