On Thu, Mar 19, 2026 at 09:58:02AM +0100, Tomasz Kaminski wrote:
> > Unfortunately testing this on i686-linux (x86_64-linux worked fine)
> > revealed
> > one further problem.
> >
> > libstdc++-v3/include/bits/random.h:446:7: note: non-uglified name 'retval'
> > where lines 445-446 are
> > friend std::strong_ordering
> > operator<=>(const type&, const type&) = default;
> > There is no retval name in the source, but build_comparison_op
> > introduces it artificially (and the decl is not DECL_ARTIFICIAL itself):
> > tree var = create_temporary_var (rettype);
> > DECL_NAME (var) = get_identifier ("retval");
> > pushdecl (var);
> > The following version of the patch fixes that by not walking bodies of
> > DECL_DEFAULTED_FN functions.
> >
> Why not change the generation function body, to use a identifier reserved
> for implementation instead? I think here we are not affected by any retval
> macros defined by users, but it still seems better to use a reserved name
> for them.
> implementation generate variables.
I think it is conceptually wrong to walk synthetized function bodies
as user has no control over those, plus the above isn't really affected
by preprocessor, so it really doesn't matter what it uses.
So all it can show up is perhaps debug info (but I don't see it in
#include <compare>
struct S {
friend std::strong_ordering operator <=> (const S &, const S &);
int s;
};
struct T {
int a; S b; S c; int d;
friend auto operator <=> (const T &, const T &) = default;
};
T a, b;
auto c = a <=> b;
-g -std=c++20 -dA).
That said, the change can be both plugin and the above get_identifier.
Jakub
