public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
       [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
@ 2021-11-10  4:57 ` pinskia at gcc dot gnu.org
  2021-11-10  8:24 ` redi at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-11-10  4:57 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-11-10
     Ever confirmed|0                           |1
             Blocks|101603                      |

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jason Vas Dias from comment #6)
> Thanks Andrew!
> 
> But, please explain, why does using a static reference cause
> anonymous namespace issues ?

So I think the diagnostic should say internal linkage rather than anonymous
namespace but only for the static case rather than the anonymous spaces.

Reduced testcase:
# 1 "t1.H"
template < int *_C_OBJ_> struct NT{};
# 2 "tM.C"
static int d;
struct D : NT<&d> {};
---- CUT ----
The filenames of the two lines need to be different.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603
[Bug 101603] [meta-bug] pointer to member functions issues

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
       [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
  2021-11-10  4:57 ` [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace pinskia at gcc dot gnu.org
@ 2021-11-10  8:24 ` redi at gcc dot gnu.org
  2021-11-10  9:01 ` redi at gcc dot gnu.org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2021-11-10  8:24 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
A variable declared 'static' has internal linkage, and so does a variable in an
anonymous namespace, which is probably the source of the mix-up in GCC's
warning.

N.B. your names like _C_ have undefined behaviour, do not use reserved names.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
       [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
  2021-11-10  4:57 ` [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace pinskia at gcc dot gnu.org
  2021-11-10  8:24 ` redi at gcc dot gnu.org
@ 2021-11-10  9:01 ` redi at gcc dot gnu.org
  2022-06-30  4:10 ` pinskia at gcc dot gnu.org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2021-11-10  9:01 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jason Vas Dias from comment #4)
> I see now I should have used 'extern C c_', and defined it in tM.C.

Or give the whole template internal linkage.

> 
> But actually, in the context in which it was used, since there was no
> other defining translation unit, and it was only instantiated in a main()
> program, I do not think the warning should have been issued. If I was
> actually trying to instantiate multiple 'class D' objects from multiple
> translation units, there would be a problem, but I was not.

Which is why it's a warning, not an error. Lots of warnings tell you about
things that might be a problem. 


> 
> And really, that '-Wsubobject-linkage' should be split into:
>   A) Detect genuine anonymous namespace use
>   B) Detect usage of static object references in headers that can be
>      included by multiple files, and issue a separate warning message like 
>       'static object reference may not be to same object\
>        if used in multiple translation units'
>      or something like that.

No, I think there is just one warning needed. It's the same problem whether
it's caused by anon namespaces or static linkage. But the warning text should
refer to internal linkage, and maybe mention either anon namespace or 'static'
in a note, depending on which was used.


> 
> It is highly confusing to claim that code uses anonymous namespaces 
> when it does not.

Agreed.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
       [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2021-11-10  9:01 ` redi at gcc dot gnu.org
@ 2022-06-30  4:10 ` pinskia at gcc dot gnu.org
  2022-06-30  4:13 ` pinskia at gcc dot gnu.org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-06-30  4:10 UTC (permalink / raw)
  To: gcc-bugs

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlame646 at gmail dot com

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 106141 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
       [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
                   ` (3 preceding siblings ...)
  2022-06-30  4:10 ` pinskia at gcc dot gnu.org
@ 2022-06-30  4:13 ` pinskia at gcc dot gnu.org
  2022-06-30  8:20 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-06-30  4:13 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #8)
> A variable declared 'static' has internal linkage, and so does a variable in
> an anonymous namespace, which is probably the source of the mix-up in GCC's
> warning.

Actually I think the warning was added before C++11 support for allowing static
variables in template args so anonymous namespaces were the only internal
linkage existing.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
       [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
                   ` (4 preceding siblings ...)
  2022-06-30  4:13 ` pinskia at gcc dot gnu.org
@ 2022-06-30  8:20 ` redi at gcc dot gnu.org
  2022-07-04 12:15 ` redi at gcc dot gnu.org
  2022-09-12 16:09 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2022-06-30  8:20 UTC (permalink / raw)
  To: gcc-bugs

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
In C++98 entities in an anonymous namespace did not have internal linkage, that
was changed for C++11. But they can still cause ODR violations. So the
diagnostic talks about anonymous namespaces because that's what causes the
potential for ODR violations, not linkage. THat was changed for C++11 so that
anonymous namespacs give internal linkage, and things with internal linkage can
now be used in templates, so the existing warning was extended to cover those
cases, but without rewording it.

In C++98 the testcase in comment 7 is simply ill-formed:

tM.C:3:15: error: ‘& d’ is not a valid template argument of type ‘int*’ in
C++98 because ‘d’ does not have external linkage

But if you change it to use an anonymous namespace it's valid in C++98:

# 1 "t1.H"
template < int *_C_OBJ_> struct NT{};
# 2 "tM.C"
namespace { int d; }
struct D : NT<&d> {};

This is valid in C++98 because 'd' doesn't have internal linkage (it's just
different in every translation unit), but it is still a potential ODR
violation, so there's a warning:

tM.C:3:8: warning: ‘D’ has a base ‘NT<(& {anonymous}::d)>’ whose type uses the
anonymous namespace [-Wsubobject-linkage]


Maybe for C++98 it should always say "anonymous namespace" since that's the
only way to trigger the warning, and for C++11 and later it should say internal
linkage, since that is true for names declared 'static' or in an anon
namespace. That seems like an easy change.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
       [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
                   ` (5 preceding siblings ...)
  2022-06-30  8:20 ` redi at gcc dot gnu.org
@ 2022-07-04 12:15 ` redi at gcc dot gnu.org
  2022-09-12 16:09 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2022-07-04 12:15 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597560.html

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
       [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
                   ` (6 preceding siblings ...)
  2022-07-04 12:15 ` redi at gcc dot gnu.org
@ 2022-09-12 16:09 ` cvs-commit at gcc dot gnu.org
  7 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-09-12 16:09 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:8ef5fa4c56c82dfbd6e8fc5e4e08c4be843abc3e

commit r13-2627-g8ef5fa4c56c82dfbd6e8fc5e4e08c4be843abc3e
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Jun 30 17:53:26 2022 +0100

    c++: Refer to internal linkage for -Wsubobject-linkage [PR86491]

    Since C++11 relaxed the requirement for template arguments to have
    external linkage, it's possible to get -Wsubobject-linkage warnings
    without using any anonymous namespaces. This confuses users when they
    get diagnostics that refer to an anonymous namespace that doesn't exist
    in their code.

    This changes the diagnostic to say "has internal linkage" for C++11 and
    later, if the type isn't actually a member of the anonymous namespace.
    Making that distinction involved renaming the current decl_anon_ns_mem_p to
    something that better expresses its semantics.

    For C++98 template arguments declared with 'static' are ill-formed
    anyway, so the only way this warning can arise is via anonymous
    namespaces. That means the existing wording is accurate for C++98 and so
    we can keep it.

            PR c++/86491

    gcc/cp/ChangeLog:

            * decl2.cc (constrain_class_visibility): Adjust wording of
            -Wsubobject-linkage for cases where anonymous
            namespaces aren't used.
            * tree.cc (decl_anon_ns_mem_p): Now only true for actual anonymous
            namespace members, rename old semantics to...
            (decl_internal_context_p): ...this.
            * cp-tree.h, name-lookup.cc, pt.cc: Adjust.

    gcc/testsuite/ChangeLog:

            * g++.dg/warn/anonymous-namespace-3.C: Use separate dg-warning
            directives for C++98 and everything else.
            * g++.dg/warn/Wsubobject-linkage-5.C: New test.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-09-12 16:09 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-86491-4@http.gcc.gnu.org/bugzilla/>
2021-11-10  4:57 ` [Bug c++/86491] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace pinskia at gcc dot gnu.org
2021-11-10  8:24 ` redi at gcc dot gnu.org
2021-11-10  9:01 ` redi at gcc dot gnu.org
2022-06-30  4:10 ` pinskia at gcc dot gnu.org
2022-06-30  4:13 ` pinskia at gcc dot gnu.org
2022-06-30  8:20 ` redi at gcc dot gnu.org
2022-07-04 12:15 ` redi at gcc dot gnu.org
2022-09-12 16:09 ` cvs-commit at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).