https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77557
--- Comment #2 from Martin <marmoo1024 at gmail dot com> ---
(In reply to Andrew Pinski from comment #1)
> The question comes down to the following is NSDMI considered part of the
> constructor or not. If not then GCC is correct here and depends on the
> following code is valid or not:
> #include <stdio.h>
> void fn () {
> static const char *d = __PRETTY_FUNCTION__;
> struct getter {
> const char * fn = d;
> };
> printf ("%s\n",getter().fn);
> };
I don't see why it would not be valid, d is static and visible to getter since
it's part of the surrounding scope. Just like a class defined inside another
class will be able to access the static variables of that class, or like a
method can see members in a class, it's just simple name lookup, goes up a
scope and up a scope until it finds the name, or not. That's my understanding
anyway.
As far as NSDMI is involved, I believe it is, but I don't know what the
standard says, that's the key. But technically, the members must be initialized
by the constructor, who else would do it, but that doesn't necessarily mean the
answer must be that gcc is doing the wrong thing. I don't know what the
standard says, or if anyone in the committee thought of this corner case. IMHO
there are arguments both ways. E.g. I didn't put it in a function (CTOR), so
the next visible __PRETTY_FUNTION__ is fn, versus, the code is pasted into the
CTOR so __PRETTY_FUNCTION__ is from the CTOR. Yet again, the standard is the
deciding factor, if it has no answer, this is undefined behavior and should be
warned about, if the standard has an applicable clause either clang or gcc is
wrong. IMHO. Either way, as a programmer I need my programs to do the same
thing with any compiler.
